Průvodce nasazením migrace

Úvod

Než začnete

Tato příručka je určena pro týmy nebo jednotlivce se zkušenostmi s konfigurací a Cisco Unified Communications Manager správou (Unified CM) a koncových bodů Cisco, včetně stolních telefonů IP, video zařízení a softwarových klientů Jabber. V tomto dokumentu jsou odkazy na produktovou a podpůrnou dokumentaci, které vám pomohou.

Tento dokument se zaměřuje pouze na přechody z Unified CM na Webex Calling více nájemců. Termín Webex Callingv tomto dokumentu vždy odkazuje na Webex Calling více nájemců.

Před zahájením migrace z Unified CM doWebex Calling, je nezbytné mít komplexní pochopení Webex Calling řešení a jeho příslušných komponent. Úspěšná migrace vyžaduje znalost Webex Calling architektury, modelů služeb, možností nasazení a souvisejících funkcí, aby bylo možné správně mapovat stávající Unified CM úlohy a navrhnout efektivní plán přechodu.

Důkladné pochopení následujících Webex Calling složek je nezbytné pro informování o účinné strategii přechodu a provozní připravenosti.

Řídicí rozbočovač
Zřizování adresářů a uživatelů
Webex Callingnástupiště
Podporované koncové body volání
Možnosti připojení PSTN
Webex Callingvytáčecí plán a správa čísel
Funkce zabezpečení a dodržování předpisů.

Další informace naleznete v tématu Cisco Preferred Architecture forWebex Calling.

Tato příručka zvýrazní nástroje a procesy, které je třeba použít během celého životního cyklu přechodu. Přechod z místního volání na novou platformu cloudových volání však může být značným ú Webex Calling silím s potenciálními obchodními, technickými a složitými výzvami. Unified CM K překonání těchto problémů má společnost Cisco k dispozici několik různých možností, které vám pomohou s vaší cestou. Je důležité zkontrolovat informace na stránce Enterprise cloud Calling — Migrace volání a porozumět každé možnosti a jak vám může každá z nich pomoci s vaší vlastní migrací.

Nástroje pro migraci Webex: samoobslužné bezplatné nástroje zabudované do centra Control Hub, které zefektivňují váš přechod na Webex Calling
Certifikovaní poskytovatelé migrace: Poskytovatelé softwaru a nástrojů ověřovaní společností Cisco, kteří vyvinuli řešení migrace, která pomáhají partnerům a zákazníkům Webex při složitých a rozsáhlých migracích. Tato řešení mohou pomoci zjednodušit, řídit a urychlit přechod na Webex Calling
Webex Setup Assist: služba migrace vedená společností Cisco, která provede zákazníky a partnery Webex Calling nasazením a konfigurací, které jsou potřebné k úspěšné migraci Unified CM uživatelů a služeb. Webex Calling

Přehled

S růstem cloudových služeb spolupráce se stále více zákazníků snaží přesunout své stávající pracovní zatížení spolupráce do cloudu vzhledem k slibům snížení celkových nákladů na vlastnictví, zjednodušené správy, nepřetržitého poskytování funkcí, zvýšeného škálování a vynikající spolehlivosti, které jsou vlastní cloudovým službám. Vzhledem k tomu, že zákazníci hledají přechod z místních služeb na služby cloudové spolupráce, je důležité, aby pochopili, co přechod obnáší, a kroky potřebné k provedení přechodu.

Účelem tohoto dokumentu je poskytnout pokyny k nasazení zákazníkům, kteří konkrétně chtějí přejít z místního prostředí Unified CM Webex Calling do cloudu. Tato příručka nasazení předpokládá, že čtenář má základní znalosti o přechodu volání mezi Unified CM aWebex Calling, včetně toho, jaké změny při provádění tohoto přechodu a jaké jsou rozdíly při přesouvání pracovní zátěže volání z místního prostředí do cloudu. Než budete pokračovat, ujistěte se, že jste zkontrolovali a znáte informace dostupné v mapě přecho du. Tento dokument mapy přechodu poskytuje informace o změnách a rozdílech tohoto přechodu.

Jak je znázorněno na obrázku Architektura místní spolupráce: řízení hovorů a vzdálený přístup, typické místní nasazení zahrnuje různé komponenty infrastruktury pro spolupráci v síti, platformu pro řízení hovorů, hraniční platformu, hardwarové a softwarové kon cové body a v některých případech dokonce platformy pro konference a plánování. V architektuře Cisco by to zahr Unified CM novalo řízení hovorů, Expressway pro vzdálený přístup a hraniční služby mezi podniky (B2B), Cisco Meeting Server/ Cisco Meeting Management pro místní konference, Unity Connection pro hlasové zprávy a uživatelský hardware (Cisco IP Phones, Cisco Desk and Room video systémy) a software () koncové body založené na IP. Cisco Jabber Tyto komponenty se mohou v některých prostředích mírně lišit, ale toto je výchozí bod pro přechod popsaný ve zbytku tohoto dokumentu.

On-Premises Collaboration Architecture: Call Control and Remote Access — ***Architektura místní spolupráce: řízení hovorů a vzdálený přístup***

Architektura znázorněná na obrázku Archit ektura místní spolupráce: řízení volání a vzdálený přístup je založena na preferované architektuře (PA) pro nasazení Cisco Collaboration Enterprise On-Premises Deployments. Další informace o prostředí Enterprise On-premise naleznete v tématu Preferované architek tury spolupráce společnosti Cisco.

Dří Webex Calling ve: Tabulka komponent místní volající infrastruktury uvádí klíčové prvky místní architektury před přechodem do clou du.

Tabulka 1. Dříve: Komponenty místní volající infrastruktury
Výrobek	Popis
Unified CM	Místní řízení hovorů poskytující služby registrace zařízení a směrování hovorů
Cisco Expressway-C/E	Edge infrastruktura poskytující funkce Mobile a Remote Access (MRA) a business-to-business (B2B) umožňující vzdáleným koncovým bodům zabezpečené připojení mimo organizaci. Expressway je nasazena ve dvojicích, aby poskytovala průjezd brá nou firewall pro externí koncové body.
Cisco Meeting Server (CMS), Cisco Meeting Management (CMM) a Cisco TelePresence Management Suite (TMS)	Místní infrastruktura hlasových, video a webových konferencí poskytující vícebodové schůzky, správu schůzek a možnosti plánování. [Volitelné]
Cisco Unity Connection	Místní platforma hlasových zpráv poskytující hlasovou schránku a funkce sjednoceného zasílání zpráv. [Volitelné]
Cisco Desk, Cisco Room, Cisco Board, Cisco IP telefony a Cisco Jabber	Zařízení založená na protokolu IP registro Unified CM vaná a poskytující hlasové hovory a videohovory

Jak je znázorněno na obrázku Rozhodnutí o přechodu: místní volání na Webex Calling, zákazníci, kteří mají místní řízení hovorů s koncovými body stolních Unified CM a video IP koncových bodů, mají na výběr přechod architektury na cloudovou architekturu. Webex Calling

Rozhodnutí musí být učiněno na základě požadavků zákazníka na funkčnost. Zákazníci, kteří mají následující požadavky, by měli před přijetím tohoto rozhodnutí pečlivě zvážit a nakonec se mohou rozhodnout ponechat kontrolu hovorů v místním prostředí:

Modely telefonů nepodporované Webex Calling
Komplexní nebo četné integrace s jinými místními systémy nebo řešeními, zejména tam, kde je replikace těchto integrací obtíž Webex Calling ná nebo nejsou k dispozici žádná ekvivalentní alternativní řešení
Komplexní číselný plán, vysoce podrobné třídy služeb nebo obojí
Omezený, omezený nebo nespolehlivý přístup k internetu
Přísné zásady ochrany osobních údajů a vlastnictví
Požadavek na shodu pro nahrávání a ukládání médií na místě nebo v zemi
Integrace třetích stran bez životaschopné alternativní Webex Calling integrace
Integrace kontaktních center, kde se kontaktní centrum inter zatím nepřesouvá do clou du.

Transition Decision: On-Premises Calling to Webex Calling — ***Rozhodnutí o přechodu: místní volání Webex Calling***

Zákazníci, kteří chtějí začít využívat služby cloudových volání, by měli zvážitWebex Calling. Tato cloudová služba volání umožňuje zákazníkovi využít globální architekturu Webex pro škálování a konektivitu. Účastníci podnikové sítě a vzdálení účastníci mimo podnikovou síť mohou komunikovat pomocí hardwarových koncových bodů založených na IP a/nebo desktopových nebo mobilních softwarových klientských aplikacích.

Tento dokument se zaměřuje na zákazníky s nasazením řízení Unified CM volání, kteří chtějí porozumět obecným krokům, úvahám a požadavkům na povolení Webex Calling nasazení, jak je uvedeno v následující části.

Základní komponenty

Cílová architektura pro tuto migraci obsahuje několik nových komponent. To zahrnuje Webex Calling službu pro cloudové volání, aplikaci Webex, Cisco Directory Connector pro integraci identit a Local Gateway (LGW) pro přístup PSTN, jakož i integraci místního volání do cloudu. Plány volání Cisco nebo Cloud Connected PSTN (CCP) zprostředkované Cloud Connect pro Webex Calling partnery jsou další možnosti přístupu k PSTN.

Jak je znázorněno na obrázku Po: Webex Calling Architektura, nové komponenty (adres Webex Calling ářový konektor, místní brána a brána přežití) jsou přidány do stávajícího místního nas azení.

After: Webex Calling Architecture — ***Po: Webex Calling Architektura***

Po: Tabulka komponent infrastruktury volání clou du uvádí nové prvky architektury po přechodu na Webex.

Tabulka 2. Po: Komponenty infrastruktury cloudových volání
Výrobek	Popis
Webex Calling	Cloudová služba volání poskytovaná z platformy Webex poskytující registraci koncového bodu a směrování hovorů
Adresářový konektor Cisco	Aplikace systému Windows běžící na počítači s doménou Windows poskytující synchronizaci identit mezi místním podnikovým úloži Active Directory štěm a úloži štěm identit organizace Webex. Pro zákazníky, kteří přecházejí z míst Active Directory ního prostředí na Entra ID, integrace identity s Webex namísto Cisco Directory Connector používá aplikaci Průvodce identifikací Entra ID.
Místní brána	Místní brána funguje jako most mezi místní jednotnou komunikační sítí zákazníka a Webex Calling cloudem. Může být nasazen místně nebo hostován partnerem a poskytuje přístup PSTN pro koncové body registrované v cloudu a integraci volání mezi Unified CM registrovanými a cloudovými koncovými body. Cisco IOS-Směrovač integrovaných služeb XE (řady ISR 1100 a 4000), řada Cisco Catalyst 8200/8300, software Cisco Catalyst 8000V Edge a různé certifikované hraniční kontroléry session (SBC) třetích stran lze použít jako LGW pro přístup postupné migrace.
Brána pro přežití	Survivalability Gateway (SGW) je brána založená na lokální síti IOS-XE, která poskytuje služby záložního volání koncovým bodům na místě Webex Calling během výpadků sítě.
Plán volání Cisco, Cloud Connect pro Webex Calling	Cisco Calling Plan a Cloud Connect for Webex Calling jsou cloudové možnosti přístupu PSTN pro koncové body. Webex Calling Přístup PSTN je usnadněn poskytovatelem cloudového PSTN a nevyžaduje žádné místní vybavení.
Aplikace Webex	Klientská aplikace běžící na desktopovém OS (Windows, Mac) nebo mobilním OS (Android, iOS) a registrovaná přímo na Webex Calling platformu pro funkčnost volání.

Přehled procesů PPDIO

Proces PPDIO znamená připravit, plánovat, navrhnout, implementovat a optimalizovat. Jedná se o strukturovanou metodiku společnosti Cisco, která řídí projekty od počátečního hodnocení přes neustálé zlepšování a zajišťuje efektivní a úspěšné nasazení nebo migrace.

Obecný popis PPDIO

Příprava: Posoudit současné prostředí, shromáždit požadavky a sladit zúčastněné strany, abyste vytvořili pevný základ.
Plán: Vypracujte podrobné plány projektů včetně časových os, zdrojů a strategií zmírňování rizik.
Návrh: Navrhněte cílové řešení přizpůsobené obchodním a technickým potřebám.
Implementace: Proveďte nasazení nebo migraci podle návrhu, ověřte funkčnost a výkon.
Optimalizace: Průběžně zlepšujte řešení po implementaci monitor ováním výkonu, zdokonalováním konfigurací a využitím automatizačních a integračních nástrojů.

Použití PPDIO pro migrační projekty Unified CM na Webex Calling

Při přechodu z Unified CM naWebex Calling, proces PPDIO poskytuje jasný plán pro zajištění hladkého a efektiv ního přechodu:

Připravit

Posoudit stávající Unified CM prostředí a připravenost na migraci
Shromažďujte podrobná data o uživatelích, zařízeních, síti a závislostech
Shromažďujte podrobnosti o poloze včetně adresy reakce na mimořádné události, počtu uživatelů, přístupu k internetu, přístupu PSTN
Identifikujte rizika a definujte rozsah projektu, abyste sladili všechny zúčastněné strany.

Plán

Vytvořte komplexní plán migrace s dávkovými plány, přiřazením zdrojů a časovými osami
Definujte úkoly, jako je upgrade firmwaru zařízení, poskytování licencí a přihlášení uživatele
Koordinujte migrační okna se společností Cisco a partnery, abyste minimalizovali narušení provozu.

Návrh

Mapování aktuálních Unified CM konfigurací, číselných plánů a uživatelských profilů na Webex Calling ekvivalenty
Navrhněte Webex Calling prostředí, včetně strategie PSTN (prozatímní a konečná), umístění, uživatelské role a integrační body, jako je místní brána (CUBE) a synchronizace adresářů
Plánujte scénáře koexistence, kde Unified CM a Webex Calling fungují současně během migrace.

Implementovat

Pomocí nástrojů pro migraci Control Hub spolu s nástroji třetích stran můžete provádět změny režimu firmwaru zařízení, konfiguraci funkcí a migraci uživatelů
Využijte hromadné operace a zřizování pomocí rozhraní API Webex pro zjednodušení rozsáhlých migrací a konfigurací
Provádění zřizování licencí, registrace zařízení a aktualizace konfigurace
Ověřte úspěšnost migrace pomocí testování a provoz ního ověření.

Optimalizace

Průběžně sledu Webex Calling jte výkon a uživatelskou zkušenost
Upřesněte konfigurace a pracovní postupy na základě provozních dat a zpětné vazby
Využijte možnosti automatizace a integrace ke zvýšení efektivity a škálovatelnosti
Podle potřeby vyřazujte starší Unified CM komponenty z provozu a poskytněte průběžnou podporu pro operace v den 2.

Tento vylepšený přístup PPDIO zajišťuje řízenou, transparentní a efektivní migraci z Unified CM doWebex Calling, s využitím nástrojů, rozhraní API a partnerského ekosystému společnosti Cisco k udržení kontinuity podnikání a zlepšení možností spolupráce.

PPDIO zpětnovazební smyčky

Přehled na vysoké úrovni zobrazený v Iteracích obrázků při provádění PPDIO ilustru je jednu zpětnovazební smyčku od optimaliz ační fáze zpět do fáze přípravy. To znamená, že po počáteční implementaci existuje neustálá příležitost k neustálému zlepšování. Každý cyklus optimalizace může identifikovat nové požadavky nebo oblasti pro vylepšení, které lze řešit prostřednictvím následných projektů nebo iniciativ. Tyto jednotlivé projekty zase sledují zavedený životní cyklus PPDIO (Prepare, Plan, Design, Implement, Optimize). Tento iterativní přístup zajišťuje, že systém zůstane v souladu s vyvíjejícími se obchodními cíli a technologickým pokrokem a podporuje kulturu neustálého zdokonalování a přizpůsobivosti.

Iterations while executing PPDIO — ***Iterace při provádění PPDIO***

Během provádění procesu PPDIO, je běžné, že zjištění v pozdějších fázích vyžadují přehodnocení a potenciálně revi zi rozhodnutí učiněných v dřívějších fázích. Například problémy, ke kterým došlo během fáze provádění, jako je identifikace nejasností návrhu nebo chybějících podrobností, mohou odhalit, že určité aspekty nebyly během fáze návrhu plně vyřešeny. V takových případech je nutné před pokračováním opakovat zpět do příslušné dřívější fáze, aby se tyto problémy vyřešily. Tento iterativní mechanismus zpětné vazby, jak je znázorněno v procesu PPDIO Unified CM s podporou obrázku, zajišťuje, že řešení je důkladně ověřeno a zdokonaleno, což v konečném důsledku přispívá k robustnějšímu a efektivnějšímu nasazení.

Unified CM assisted PPDIO process — ***Unified CMasistovaný proces PPDIO***

Při přechodu z Unified CM naWebex Calling, každá fáze procesu PPDIO může významně těžit z informací shromážděných ze stáv ajícího Unified CM prostředí. Z aktuální Unified CM konfigurace lze například extrahovat komplexní inventáře uživatelů, telefonních čísel, funkcí volání a komponent číselného plánu. Tato data doplňují informace poskytované přímo zúčastněnými stranami a pomáhají zefektivnit plánování a projekční činnosti. Využití vhodných nástrojů k automatizaci extrakce a analýzy dat nejen zvyšuje přesnost, ale také urychluje celkový proces. Využitím poznatků ze stávajícího nasazení Webex Calling může být přechod proveden efektivněji než tradiční implementace greenfield, při současném dodržování strukturované metodiky PPDIO. Tento proces je znázorněn v procesu PPDIO Unified CM s podporou obrázku.

Migrační přístup

Při plánování přechodu z místního prostředí Unified CM naWebex Calling, musíte určit, jak k této cestě přistupujete. Nejprve se budete muset rozhodnout, zda bude migrace probíhat flash-cut (vše najednou) nebo postup ný přístup (migrace skupin uživatelů/zařízení po delší dobu).

Provádění migr ace typu flash přesune všechny vaše uživatele a zařízení nejrychleji. Pomocí této metody přesunete všechny uživatele a zařízení z míst Unified CM ního Webex Calling prostředí současně. V podstatě se jedná o jediné migrační okno pro všechny uživatele a zařízení. Po dokončení této migrace budou všichni vaši uživatelé a zařízení na Webex Calling platformě a veškerá vaše Unified CM infrastruktura může být vyřazena z provozu. Mnoho organizací však tento přístup nemůže použít kvůli rozsahu a velikosti nasazení volání.

Druhým přístupem je postup ná migrace. Většina organizací tento přístup použije, protože poskytuje lepší kontrolu, správu a škálování s migrací. Je také vhodnější pro větší nasazení a/nebo nasazení UC ve více oblastech. Proto, tento dokument se zaměřuje na postupný přístup se dvěma kroky přechodu.

Jak je znázorněno na následujícím obrázku Postupný přechod volání: Hybridní a cloud, první fáze přechodu (fáze 1) vede k nasazení koexistence s duálními vol acími prostředími. V této fázi dochází k přechodu na některé uživatele, zařízení a softwarové klienty, Webex Calling zatímco jiní jsou stále na místním řízení ho Unified CM vorů. Konečná fáze přechodu (fáze 2) má za následek čistě cloudové volání prostředí, kde byli všichni uživatelé, zařízení a měkcí klienti plně převedeni na Webex Calling platformu.

Jak dlouho trvá, než organizace zcela přejde na cloudové volání, se bude lišit v závislosti na aktuálním nasazení. V některých případech může organizace provést počáteční přechod a zůstat ve fázi řízení dvojího volání (fáze 1) po delší dobu (měsíce nebo dokonce roky), zatímco v jiných případech může organizace plně přejít na Webex Calling (fázi 2) ve velmi krátkém období (týdny nebo měsíce). Tento dokument je určen k pokrytí obou fází (fáze 1 - koexistence a fáze 2 - plně přechodná).

Phased Calling Transition: Hybrid and Cloud — ***Postupný přechod volání: hybridní a cloudové***

Je možné, že některé organizace mohou udržovat koexistenční nasazení řízení duálního volání neomezeně dlouho bez plánů na úplný přechod na cloudové volání.

Druhým hlediskem je, jak přesunete uživatele, zařízení a softwarové klienty z míst ního řízení hovorů na řízení cloudových hovorů. Doporučený přístup je třífázový přechod . Obrázek Doporučený třífázový přechod níže rozděluje tento přístup do 3 fází.

Recommended 3-Phase Transition — ***Doporučený třífázový přechod***

Předmigrace: Tato fáze se zaměřuje na přípravu Webex i Unified CM prostředí pro migraci. Nejde o volání konkrétního plánování nebo konfigurace a zaměřuje se na dokončení činností, které lze provést nyní a před zahájením jakéhokoli projektu Webex Calling migrace. Cílem je vybudovat základ pro obě prostředí pro přípravu na migraci.

Příprava na migraci: V této fázi začíná úsilí o přípravu na migraci do Webex Calling. Zde je třeba přezkoumat a aktualizovat obchodní a technické požadavky. Neprovádějte jen zved ání a přesun toho, co je v současné době nasazeno, ale místo toho předefinujte obchodní a technické požadavky, které vaše společnost potřebuje dnes i v budoucnu, využitím síly. Unified CM Webex Calling Kromě toho je to fáze, kdy dokončíte svůj návrh, plánování konfigurace a plánování/plán migrace.

Migrace (zavádění a vyřazení z provozu): V této fázi dochází ke skutečné migraci uživatelů, zařízení, telefonních čísel a softwarových klientů. Jak bylo uvedeno výše, lze tuto fázi dokon čit pro každého najednou (flash-cut) nebo přes více oken změn (fáz ový řez). Plány přijetí koncových uživatelů, školení, a komunikace jsou zásadní, takže vaši uživatelé jsou si vědomi změn, jak používat novou platformu pro volání, a věděli, kdy ke změně dojde. Posledním krokem je vyřazení veškeré místní infrastruktury UC , která se již nepoužívá.

Fáze před migrací obsahuje aktivity (povinné, doporučené a volitelné), na kterých můžete okamžitě začít pracovat. Doporučujeme je dokončit dříve než později a nejlépe před zahájením projektu. Dokončení některých činností může trvat déle, proto jejich dřívější spuštění pomůže zefektivnit váš skutečný projekt migrace.

Níže uvedený obrázek Čin nosti před migr ací zdůrazňuje pět konkrétních kategorií činností, které souvisejí s Webex Calling migrací.

Pre-Migration Activities — ***Předmigrační činnosti***

Připravit

Obchodní a technické požadavky

Při plánování migrace z do je zásadní během fáze plánování důkladně shromáždit technické i obchodní požadavky. Tento krok zajišťuje, že migrace bude v souladu s provozními cíli a technickými mož nostmi vaší organizace a minimalizuje rizika a přerušení provozu.

Proč je shromažďování požadavků důležité:

Sladí obchodní cíle: Por ozumění obchodním potřebám pomáhá přizpůsobit migraci tak, aby podporovala klíčové pracovní postupy, uživatelské prostředí a plány růstu.
Zajišťuje technickou kompatibilitu: Včasná identifikace technických požadavků zabraňuje problémům s integrací se stávající infrastrukturou, sítí a koncovými body.
Usnadňuje plánování zdrojů: Jasné požadavky pomáhají přesně odhadnout časové osy, náklady a potřebné zdroje.
Snižuje rizika: V časné odhalení potenciálních problémů umožňuje proaktivní řešení, snižuje prostoje a přerušení služeb.

Obchodní požadavky

Mezi typické obchodní požadavky patří:

Počet uživatelů a umístění, které mají být migrovány
Požadované funkce a služby (například směrování hovorů, hlasová schránka, konference, automatická obsluha, fron ty hovorů)
Zásady dodržování předpisů a zabezpečení
Rozpočtová omezení a očekávání nákladů
Potřeby školení a podpory uživatelů
Časová osa migrace a úvahy o kontinuitě podnikání.

Shro mažďování požadovaných funkcí a služeb je kritickým krokem k zajištění toho, aby nový systém splnil obchodní potřeby. Při shromažďování těchto požadavků je důležité nejen zvážit, co je aktuálně nakonfigurováno, ale pokusit se shromáždit skutečné požadavky od obchodních subjektů, které budou systém používat . V opačném případě existuje riziko, že plán bude založen na dlouhodobých předpokladech. Nezapomeňte vyhodnotit další nebo vylepšené funkce dostupné v něm, které nemusí existovat, například volání na cloudu, pokročilé fronty hovorů, , a. To pomáhá při plném využití výhod cloudové platformy.

Při vyhodnocování aktuální konfigurace v, je důležité si uvědomit, že ne všechna stávající nastavení mohou zůstat nezbytná kvůli vyvíjejícím se požadavkům během celého životního cyklu systému. Důraz by měl být kladen na identifikaci a zachování pouze těch konfigurací, které odpovídají současným a budoucím potřebám nasazení.

Zaměřte se více na to, co potřebujete, než na to, co máte.

Zásady dodržování předpisů a zabezpečení jsou rozhodující při migraci z doWebex Calling, aby bylo zajištěno, že nový cloudový komunikační systém bude dodržovat právní, regulační a organizační standardy.

Dodržování předpisů: Organizace musí ověřit, zda splňují odvětvové předpisy, jako jsou GDPR, HIPAA nebo SOX, které řeší požadavky na ochranu osobních údajů, uchovávání a zpracování dat, jakož i mandáty specifické pro jednotlivé země týkající se pobytu dat, obcházení mýtného a lokality médií.
Zabezpečení dat: Zajištění šifrování hlasových a signálních dat při přenosu i v klidu , aby byla chráněna před zachycením nebo neoprávněným přístupem.
Řízení přístupu: Definování a vynucení ověřování uživatelů, autorizace a přístupu založeného na rolích, aby se zabránilo neoprávněnému použití komunikačních prostředků.
Audit a monitorování: Im plementace funkcí protokolování a monitorování pro sledování přístupu a využití pro audity shody a vyšetřování bezpečnostních incidentů.
Sladění zásad: Sladění migrace se stávajícími firemními zásadami zabezpečení, včetně zabezpečení koncových bodů, segmentace sítě a plánů reakce na incidenty.
Zajištění bezpečnosti dodavatele: Vyhodnocení bezpečnostních certifikací společnosti Cisco a osvědčení o shodě s cílem zajistit důvěryhodnost.

Řešení těchto zásad dodržování předpisů a zabezpečení během fáze plánování pomáhá zmírnit rizika, vyhnout se právním sankcím a zachovat integritu a důvěrnost komunikace po celou dobu migrace i po ní.

Potřeby školení a podpory uživatelů jsou základními složkami během migrace z do, aby byl zajištěn hladký přechod a přijetí uživatelů. Mezi klíčové aspekty patří:

Školicí programy: Vytvořte školení na míru pro různé skupiny uživatelů (koncoví uživatelé, administrátoři, pracovníci technické podpory), abyste je seznámili s funkcemi, uživatelskými rozhraními a novými pracovními postupy.
Dokumentace: Poskytujte přehledné a přístupné uživatelské příručky, časté dotazy a rychlé referenční materiály, včetně zdrojů Co je nového a odliš ného a podrobných návodů před a po (ve formátu videa nebo rychlého průvodce), které uživatelům pomohou při přizpůsobení se aktualizovanému prostředí po migraci.
Správa změn: Proaktivně komunikujte změny, abyste spravovali očekávání uživatelů a snížili odolnost.
Struktura podpory: Vytvořte specializovaný tým podpory nebo eskalační cestu, abyste rychle řešili problémy uživatelů během migrace a po ní.
Průběžné vzdělávání: Plánujte průběžné aktualizace školení, jakmile budou vydány nové funkce nebo aktualizace .
Mechanismy zpětné vazby: Implementujte kanály pro uživatele k hlášení problémů a poskytování zpětné vazby ke zlepšení procesů školení a podpory.

Řešení těchto potřeb školení a podpory během fáze plánování pomáhá minimalizovat narušení, zvyšuje důvěru uživatelů, a maximalizuje výhody migrace na.

Technické požadavky

Pro úspěš ný přechod z do země je třeba shromáždit a zdokumentovat několik klíčových technických požadavků, včetně podrobností pro:

Připravenost sítě a kapacita šířky pásma

Komplexní posouzení sítě je zásadní pro zajištění toho, aby vaše stávající infrastruktura mohla podporovat nové Webex Calling prostředí. To zahrnuje:
- Analýza šířky pásma: Vyhodnocení současného a předpokládaného využití šířky pásma pro zpracování hlasového, video a datového provozu bez přetížení.
- Quality of Service (QoS): Implementace zásad QoS pro upřednostnění hlasového provozu a minimalizaci latence, chvění a ztráty paketů.
- WAN a připojení k internetu: O věření, zda připojení WAN a připojení k internetu splňují požadavky na cloudové volání, včetně možností redundance a převzetí služeb při selhání.
- Konfigurace brány firewall a NAT: Zajištění, aby nastavení brány firewall a NAT umož ňovalo požadovanou signalizaci a přenos médií pro.
Integrace se stávajícím systémem

Bezproblémová integrace se stávajícími podnikovými systémy je nezbytná pro uživatelskou zkušenost a kontinuitu pracovního postupu:
- Adresářové služby: Posouzení integrace s podnikovým adresářem pro automatizované zřizování a ověřování uživatelů.
- CRM a obchodní aplikace: Identifikace integračních bodů se systémy řízení vztahů se zákazníky a dalšími kritickými aplikacemi pro podnikání.
- Legacy PBX Interworking: Plá nování strategií koexistence nebo postupné migrace, pokud během přechodu zůstanou starší telefonní systémy.
Kompatibilita a zřizování koncových bodů

Všechny koncové body včetně stolních telefonů, softwarových telefonů a mobilních zařízení by měly být vyhodnoceny z hlediska kompatibility :
- Podpora zařízení: Pot vrzení, zda jsou stávající IP telefony a zařízení podporovány nebo identifikace požadovaných výměn.
- Zřizovací procesy: Zaved ení automatizovaných nebo zjednodušených metod zajišťování pro efektivní začlenění koncových bodů.
- Aktualizace firmwaru a softwaru: Plánování nezbytných aktualizací pro zajištění interoperability a zabezpečení.
Konfigurace zabezpečení a standardy šifrování

Bezpečnost je v cloudové komunikaci prvořadá:
- Šifrování: Vynucení end-to-end šifrování pro signální a mediální toky v souladu s osvědčenými postupy zabezpečení společnosti Cisco.
- Ověřování a řízení přístupu: Impl ementace mechanismů zabezpečeného ověřování (jako je SSO, vícefaktorové ověřování) a granulární kontroly přístupu uživatelů.
- Dodržování předpisů: Zajištění, aby řešení splňovalo příslušné regulační a průmyslové standardy (například GDPR, HIPAA).
- Monitorování zabezpečení: Integrace s nástroji SIEM a nastavení upozornění na potenciální bezpečnostní incidenty.

Tabulka 1. Příklad hodnocení
Požadavek	Klíčové úvahy
Připravenost sítě a šířka pásma	Šířka pásma, QoS, WAN/Internet, Firewall/NAT
Integrace se stávajícími systémy	Adresář, CRM, pobočková ústředna, e-mail/kalendář
Kompatibilita a zřizování koncových bodů	Podpora zařízení, zřizování, aktualizace firmwaru
Konfigurace zabezpečení a šifrování	Šifrování, autentizace, dodržování předpisů, monitorování zabezpečení
Školení uživatelů a správa změn	Školicí programy, dokumentace, změna komunikace
Přenositelnost čísel a vytáčecí plán	Migrace/přenesení čísel, překlad číselného plánu
Integrace třetích stran	Stránkování, kontaktní centrum, fax, analogová zařízení

Připravenost a požadavky na síť

Připravenost k síti je rozhodující pro úspěšnou migraci na jakékoli cloudové řešení volání, jako je. Špatné plánování sítě může vést ke zhoršení kvality hovorů, přerušení hovorů a nešťastným uživatelům. Zákazníci musí před migrací provést posouzení sítě. Doporučuje se potvrdit dostupnost šířky pásma sítě pro očekávaný objem hovorů, zajistit splnění požadavků na kvalitu služeb (QoS) a porozumět různým portům, které musí být otevřeny v hraničním bráně firewall.

Spolehlivé síťové připojení s dostatečnou kvalitou služeb (šířka pásma, ztráta paketů, RTT) je základním požadavkem k zajištění nejlepšího možného uživatelského zážitku od začátku do konce pro všechny koncové body, klienty a aplikace schopné hlasu a videa.

Zákazníci a partneři mají přístup k možnostem připojení nad rámec OTT-Internetu (Over-the-Top) , které mohou optimalizovat připojení včetně Webex Edge připojení Connect. Další informace o podrobnostech návrhu Webex Edge služby Connect naleznete v tématu Cisco Preferred Architecture for Webex Edge Connect forWebex Meetings, Calling Multi-Tenant a Dedicated Instance.

Zákazníci mohou využít cScan pro hodnocení sítě, které poskytuje informace o kvalitě sítě zákazníka, kolik hovorů lze navázat, latenci atd. Další informace o nástroji cScan naleznete v tématu Použití nástroje cScan k testování kvality Webex Calling sítě.

Chcete-li zajistit, aby byla síť připravena k migraci, zvažte následující kontrolní seznam:

Plánování šířky pásma

Vypočítejte souběžná volání na web, abyste zajistili dostatečnou šířku pásma pro předcházející a navazující provoz a zahrňte prostor pro další kritický provoz a budoucí růst.

Tabulka výpočtů šířky pásma typu Webex Calling volání zobrazuje typy volání dostupné s nasazením spolu s kodekem a maximální šířkou pásma požadovanou pro každý typ hovoru. Jak je uvedeno v tabulce výpočtů šířky pásma typu ho Webex Calling voru, požadovanou šířku pásma zvukového volání pro každý typ hovoru lze vypočítat pomocí následujícího obecného vzorce:

Počet očekávaných souběžných hovorů* Šířka pásma na hovor založená na kodeku = Požadovaná propustnost sítě.

Tabulka 2. Webex Calling výpočty šířky pásma typu volání
Typy hovorů	Kodek - šířka pásma	Výpočty šířky pásma
/Stolní telefon ->	OPUS - 70 kb/s	Počet souběžných hovorů* 70 kbps = Požadovaná propustnost sítě
/Stolní telefon -> Stolní telefon	OPUS — 70 kb/s	Počet souběžných hovorů* 70 kbps = Požadovaná propustnost sítě
/Stolní telefon -> PSTN přes LGW	G.711 — 80 kb/s	Počet souběžných hovorů* 80 kbps = Požadovaná propustnost sítě
/Stolní telefon -> PSTN přes Cloud PSTN (např. Plán volání Cisco)	G.711 — 80 kb/s	Počet souběžných hovorů* 80 kbps = Požadovaná propustnost sítě
/Stolní telefon -> Enterprise přes LGW	G.722 — 80 kb/s	Počet souběžných hovorů* 80 kbps = Požadovaná propustnost sítě
/Stolní telefon -> hlasová schránka	OPUS — 70 kb/s	Počet souběžných hovorů* 70 kbps = Požadovaná propustnost sítě

Sčítáním souběžné požadované propustnosti sítě na typ hovoru lze určit celkový potenciální požadavek na šířku pásma pro konkrétní lokalitu.

Všechny nohy volání jsou vždy ukotveny na přístupových SBC. K určení požadované šířky pásma internetu pro jakékoli dané místo je třeba vzít v úvahu nejen interlokační hovory, ale také volání uvnitř umístění a volání do a z místní brány v tomto místě. Například hovor uvnitř webu mezi dvěma telefony MPP by vyžadoval plný duplex až 2 x 70 kb/s na přístupu k internetu dané lokality.

Tabulka příkladů výpočtu Webex Calling šíř ky pásma ukazuje příklad úplného cvičení výpočtu šířky pásma za předpokladu, že všechna zařízení jsou na stejném místě.

Tabulka 3. Webex Calling příklady výpočtu šířky pásma
Typy hovorů	Počet souběžných hovorů	Celková šířka pásma
Aplikace Webex/Stolní telefon → Aplikace Webex	15	2 * 15 * 70 kb/s = 2 100 kb/s
Aplikace Webex/Stolní telefon → Stolní telefon	15	2 * 15 * 70 kb/s = 2 100 kb/s
Aplikace Webex/Stolní telefon → PSTN přes LGW	50	2 * 50 * 80 kb/s = 8 000 kb/s
Aplikace Webex/Stolní telefon → PSTN přes Cloud Connect pro Webex Calling	0	0* 80 kb/s
Aplikace Webex/Stolní telefon → Enterprise přes LGW	15	2 * 15 * 80 kb/s = 2400 kb/s
Aplikace Webex/Stolní telefon → Webex Calling Hlasová schránka	5	5 * 70 kb/s = 350 kb/s
Celkový počet hovorů/šířka pásma	100 hovorů	14 950 kb/s/14,95 Mb/s

Všechny hodnoty šířky pásma ve výše uvedených tabulkách odkazují na šířku pásma IP. Šířka pásma linky je vyšší v závislosti na zapouzdření WAN.
Šířka pásma ve výše uvedených tabulkách je pro zvuk ové hovory. Pokud jde o šířku pásma videohovorů, aplikace Webex a telefony MPP 8845/65 podporují video H.264 s maximálním rozlišením 720p při maximální šířce pásma 1 500 kb/s na hovor. Množství šířky pásma spotřebované v kterémkoli bodě během hovoru však bude kolísat na základě proměnné přenosové rychlosti vlastní video komunikaci.

Kvalita služeb (QoS)

Implementujte zásady QoS v místním prostředí, abyste upřednostnili provoz v reálném čase a zajistili udržování QoS napříč přepínači, směrovači a firewally.
Cíle latence, chvění a ztráty paketů

Následující prahové hodnoty se doporučují pro optimální kvalitu hlasu při volání přes internet (Over-the-Top) (OTT):
- Latence - méně než 100 ms jednosměrná
- Jitter - méně než 10 ms
- Ztráta paketů - 0,5% nebo méně.
Firewall a NAT

Zkontrolujte, zda je brána firewall nakonfigurována tak, aby umožňovala provoz, jak je uvedeno v článku dostupném na stránce Referenční informace o portu pro Webex Calling. Dále povolte přístup k doménám a rozsahům IP uvedeným ve stejném průvodci a vyhněte se SIP ALG, protože narušuje signalizaci SIP. Je třeba se vyhnout mediálnímu provozu prostřednictvím proxy serverů.
DNS a NTP

Zajistěte správné rozlišení DNS domén a spolehlivé servery NTP pro synchronizaci hodin zařízení pro ověření a protokolování certifikátů TLS.
Plánování převzetí služeb při selhání

Zvažte stávající datová připojení poskytovatele (MPLS, SD-WAN atd.) a obecně plánujte přímý přístup k internetu na každém místě v rámci nas azení. Plánujte redundantní internet ové připojení tam, kde je vyžadována vysoká dostupnost. Protože budete spotřebo vávat cloudové služby, je základním požadavkem spolehlivé připojení k internetu s dostatečnou šířkou pásma. Tento přechod byste měli přehodnotit, pokud připojení k internetu v lokalitách vaší organizace není obecně spolehlivé s nízkou latencí a dostatečnou propustností pro vyšší a následnou propustnost.
Odolnost webu

Odolnost webu zajišťuje, že vaše podnikání je vždy dosažit elné, i když se vaše síťové připojení přeruší. Site Survivalability používá bránu ve vaší místní síti k poskytování služby záložního volání koncovým bodům na místě v situacích, kdy dojde k přerušení síťového připojení. Pokud obchodní požadavky vyžadují nepřetržité volání v případě vý padku sítě, zvažte přežití webu s místní bránou Survivalability Gateway (SGW). Další informace o kontrole přežití webu, viz Pře žití webu pro. Webex Calling

Nastavení cloudové komunikace propojené

Cloud Connected UC (CCUC) je cloudové řešení pro správu a analýzu navržené tak, aby poskytovalo centralizovanou viditelnost, správu a přehledy pro místní nasazení (například) i cloud (Unified CM). Funguje jako most mezi tradičními místními prostředími a clou dovými službami společnosti Cisco a podporuje organizace na cestě migrace z do.

Během přechodu na, CCUC hraje zásadní roli při zefektivnění procesu migrace usnadněním shromažďování komplexních dat ze stávajícího nasazení Unified Communications. CCUC pomáhá s klíčovými úkoly přechodu, jako je migrace zařízení, funkcí a kontaktů uživatelů, stejně jako automatizace aktualizací firmwaru pro podporované IP telefony. Díky centralizovanému přehledu a správě pomáhá CCUC zajistit plynulejší a efektivnější migraci.

Společnost Cisco důrazně doporučuje, aby byl CCUC nasazen a nasazen brzy v přechodovém projektu, nejlépe před nebo během fáze přípravy. To umožní přehled a schopnosti potřebné k důkladnému vyhodnocení, inventarizaci a plánování následných migračních aktivit a zahájení vaší cesty k budoucím hybridním schopnostem.

Posouzení současného prostředí

Klíčovou činností při plánování migrace je posouzení aktuálního místního prostředí a nasazení. To poskytuje přehled o tom, na jaké potenciální změny mohou být nutné k úspěšnému přechodu. Umožňuje také posoudit klíčové prvky platformy ve srovnání se stávajícím místním nasazením. Pomocí těchto informací můžete určit, jaké konkrétní úkoly jsou pro přechod vyžadovány a jaké změny chcete provést, abyste splnili své obchodní a technické požadavky a případy použití.

V rámci tohoto úsilí je důležité přezkoumat následující aspekty.

Licencování

Pochopení aktuální struktury licencí stávajícího nasazení je klíčové při přípravě na migraci na. Proveďte posouzení licencí následujících oblastí vašeho stávajícího místního řešení Cisco.

Nástupiště

Schopnost plně formulovat, co je aktuálně licencováno na vaší základní platformě, bude rozhodující při spolupráci s vaším týmem účtu nebo partnerem na určení nejlepší cesty k flexibilní licencování . je licencován pomocí flex licencování. Další informace o flexibilním licencování naleznete v tématu Cisco Collaboration flex plan.
Uživatelé a zařízení

Určete, jakou kategorii licencí vaši stávající uživatelé a zařízení vyžadují. To bude použito k určení, jaký typ licence je vyžadován pro uživatele a zařízení. nabízí několik typů licencí, včetně licencí Professional a Standard pro uživatele a licencí Professional a common area pro pracovní prostory. Další informace o licencování zařízení naleznete v datovém listu dostupném na stránce Licencování zařízení.
Místní brána

Pokud je Cisco Unified Border Element (CUBE) vyžadován pro přístup PSTN pro tento přechod, je třeba zvážit také licencování CUBE. Úvahy o licencování CU BE jsou popsány dále v tomto dokumentu.

Místa/Stránky

Při plánování tohoto přechodu je třeba vzít v úvahu počet a typy lokalit (velké centrální, regionální, pobočkové atd.) v rámci stávajícího nasazení. Plné poroz umění stávajícím lokalitám nasazení pomůže při strategickém plánování úspěšného přechodu, zejména pokud jde o určení, které lokality migrovat a v jakém pořadí. Při rozhodování o migraci bude rozhodující porozumět podrobným požadavkům na vytáčecí plán (číslování, návyky vytáčení, třídy omezení atd.), připojení k síti webu a šířku pásma (internet, WAN, LAN) a přístupu PSTN (místní nebo centralizovaný, IP nebo TDM) pro každý web. Další informace o běžných modelech nasazení a klíčových aspektech naleznete v informacích o modelech nasazení spolupráce, které jsou k dispozici v dokumentu SRND spolupráce.

Dalším důležitým aspektem nasazení při přechodu na umístění je dostupnost umístění. má různé funkce, předplatné a zařízení, která jsou k dispozici v závislosti na umístění vašeho nasazení. Další informace o geografické dostupnosti naleznete v části Kde je Webex k dispozici? .

Nakonec je důležité pochopit dopad, který bude mít přechod na další služby spolupráce. Na základě cíle tohoto dokumentu je obecným předpokladem, že pokud mají být zacho vány stávající služby spolupráce mimo pracovní zátěž volání, očekává se přechod na výše uvedené hybridní nasazení fáze 1. Mezi příklady služeb spolupráce, které mohou vyžadovat hybridní nasazení, patří místní kontaktní centrum, které ještě nebylo migrováno do kontaktního centra Webex, a těsné integrace do systémů, jako jsou stránkovací systémy a fakturace. Další informace o přechodu dalších úloh spolupráce a služeb naleznete v tématu Přec hody spolupráce.

Inventarizace stávajících zařízení/klientů

Před zahájením přechodu je důležité inventarizovat stávající hardwarové a softwarové koncové body. Úplný seznam typů/modelů zařízení, verzí hardwaru, typů softwarových klientských operačních systémů a množství zajistí, že budete moci adekvátně naplánovat přecho d zařízení a zmírnit dopad na zařízení, která nelze migrovat na cloudové volání. Inventář by měl být použit k určení zařízení k přechodu a zařízení, která mají být vyměněna před přechodem.

Stolní telefony

Pro audio a video stolní telefony jsou podporovány pouze stolní telefony řady 6800,7800,8800 a 9800. Toto je podmnožina telefonů Cisco IP, které jsou podporovány. Existují některé modely a verze telefonů 6800,7800 a 8800, se kterými nelze použít. Další informace o podporovaných modelech a verzích hardwaru naleznete v části Pod porovaná zařízení pro Webex Calling.

IP telefony řady Cisco 6800 nelze upgradovat z podnikového firmwaru na multiplatformní (MPP) firmware, který je vyžadován pro. Proto musí být všechny telefony 6800 registrované pro běžící firemní firmware nahrazeny modelem 6800 MPP nebo jiným podporovaným modelem telefonu.

IP telefony řady Cisco 7800 a 8800 musí být před přechodem a registrací upgradovány na firmware Multiplatform Phone (MPP). Chcete-li zjistit, které modely 7800 a 8800 a verze hardwaru podporují firmware MPP, přečtěte si článek Převod IP telefonů Cisco řady 7800 a 8800 mezi firmwarem Enterprise a MPP.

Modely 8845,8865 a 8865NR dosáhly konce prodeje a nedoporučuje se na ně migrovat.

Starší verze telefonů řady 8800 (8811,8841,8851, 8851NR, 8861) se nedoporučují používat. Webex Calling Telefony s hardwarovou verzí VID 14 nebo starší se zaregistrují, ale mohou se vyskytnout některé problémy s výkonem kvůli hardwaru.

Stolní telefony řady 9800 běží na PhoneOS, který podporuje jak registraci, tak i registraci. Proto lze tyto telefony přepnout bez upgradu firmwaru.

Všechny ostatní IP telefony budou muset být nahrazeny telefony řady 6800,7800,8800 nebo 9800 podporovanými. Webex Calling Další informace o podporovaných telefonech IP a stolních telefonech naleznete v článku Podporovaná zařízení pro Webex Calling.

Koncové body videa

Koncové body pro osobní a pokojové video, včetně řady Cisco Board, řady Room a Desk, lze nati vně zaregistrovat do protokolu SIP. Kterýkoli z těchto koncových bodů, které potřebují uskutečňovat zvukové hovory a/nebo volání PSTN, vyžaduje volací licenci:

Sdílená zařízení v konferenčních místnostech, společenských prostorách atd. vyžadují licenci Professional Workspace nebo Workspace.

Osobní zařízení koncového uživatele vyžaduje profesionální nebo standardní licenci.

Určete, kolik koncových bodů videa je registrováno a kolik se používá k uskutečňování zvukových hovorů. Je možné, že některé koncové body videa mohou být použity pouze pro připojení ke schůzkám nebo pro videohovory SIP. V obou případech je ještě potřeba migrovat koncové body, než budou servery vyřazeny z provozu, nicméně to pomůže určit, kolik z nich bude potřebovat licence k dalšímu telefonování.

Když jsou video zařízení přesunuta z registrace do, URI pro tyto koncové body se změní, protože jsou nyní registrovány v cloudu.

Modely telefonů 8845,8865 a 8875 jsou osobní video telefony, které jsou podporovány.

Měkké klienty

Je jediným softwarovým klientem podporovaným, na rozdíl od Unified CM kterého podporuje aplikaci Webex i Jabber, a je novým výchozím softwarovým klientem pro koncové uživatele.

V závislosti na režimech nasazení implementovaných pro Jabber (režimy pouze IM, pouze telefon a/nebo plné UC) možná budete muset zvážit také přechod úloh Zprávy a/nebo Meetings z Jabber na. Může být nasazen pouze v telefonickém režimu, pokud bude použit jako klient pouze pro volání, nebo může být nasazen jako pl nohodnotný v Webex Suite případě jiných úloh, např. Webex Messaginga/nebo Webex Meetings jsou přecházeny do aplikace s voláním.

Vylepšuje zážitek koncového uživatele poskytováním funkcí AI, jako je audio/video inteligence, přepis hovorů a další. Další informace naleznete na adrese https://www.webex.com/all-new-webex.

Před přesunem uživatelů na něj budete muset převést jejich klienty Jabber na. K dokončení tohoto přechodu máte dvě možnosti.

Než je převedete na

Když je převedete na.

Pro usnadnění počátečního přechodu na, doporučuje se použít možnost 1 a přesunout uživatele nejprve na voláním. To dává uživatelům čas na seznámení se s novou aplikací, zatímco stále používají stávající místní volací platformu. Jakmile budete připraveni přesunout uživatele, nakonfigurujete je tak, aby se zaregistrovali na platformě cloudových volání.

Další informace o těchto dvou možnostech najdete v tématu C esta migrace - jeden nebo dva kroky? .

Úplný seznam podporovaných zařízení pro, viz Podporovaná zařízení pro Webex Calling.

Ověřte způsobilost zařízení

Jak již bylo zmíněno dříve, podporuje podmnožinu telefonů Cisco IP a vyžaduje jiný typ firmwaru pro telefony řady 7800 a 8800. Unified CMtelefony používají firmware Enterprise, zatímco telefony spouštějí firmware Multiplatform Phone (MPP). Doporučuje se ověřit, které registrované telefony jsou způsobilé k upgradu na firmware MPP během fáze Prepare. To vám dává čas na nahrazení nezpůsobilých telefonů jedním z podporovaných modelů telefonů nebo na identifikaci alternativního plánu, jako je přesun uživatele pouze do aplikace Webex.

Pro určení způsobilosti telefonů má Control Hub vestavěný nástroj s názvem Migrace telefonu do Webex Calling. Pokud používáte tento nástroj ke kontrole způsobilosti zařízení, vyberte možnost Migrace Generovat pouze licenci zařízení.

Možnost nástroje Control Hub k ověření způsobilosti Unified CM telefonů pro Webex Calling

Tato možnost umožňuje nahrát soubor CSV obsahující telefony, takže můžete zkontrolovat způsobilost každého telefonu. Výběrem této možnosti migrace ne přidá telefony, protože jste stále ve fázi přípravy a ještě nejste připraveni to udělat. Další informace naleznete v tématu Migrace telefonu do Webex Calling.

Je možné, že některé telefony se mohou vrátit s nezná mou způsobilostí. Je to obvykle proto, že není schopen ověřit některé informace o telefonu v back-endovém systému. U všech telefonů, které mají stav Nezná mý, máte dvě možnosti, jak ověřit, zda mají nárok na upgrade na firmware MPP.

Ručně zkontrolujte každý telefon a ověřte model a verzi hardwaru (PID VID)

7800/8800 telefonní štítek s informacemi o modelu a verzi hardwaru

Použijte nástroj připravenosti telefonů Cisco IP

Stáhněte si nástroj z https://github.com/joemar2/mpp_readiness_check.

Tento nástroj není oficiálním nástrojem Cisco ani není podporován TAC. Má maximální podporu, ale je zdarma k použití.

Tento nástroj musí být spuštěn na místním počítači, který má přístup k serverům a telefonům IP. Má možnost povolit přístup na web na IP telefonech, což je doporučeno a potřebné k dosažení nejlepších výsledků. Proto by měl být používán mimo pracovní dobu, aby nedošlo k narušení koncových uživatelů. Výstup nástroje poskytuje zprávu se seznamem telefonů řady 7800 a 8800, které jsou způsobilé pro upgrade na firmware MPP. Protože přímo přistupuje k telefonu, může ověřit nezná má zařízení, která byla nahlášena z nástroje Control Hub.

Zpráva o nástroji připravenosti telefonů Cisco IP

Uživatelé

Jedním z nejdůležitějších přípravných kroků k zajištění úspěšné migrace je správné zřizování uživatelů. Musíte správně naplánovat pro všechny uživatele, i když provádíte postupnou migraci. Uživatelé musí být zřízeni pro některou z následujících možností:

Nasazení s voláním

Nasazení s

Konfigurace služeb pro uživatele

Umožnit vyhledávání uživatelů v adresáři (click-to-call, User contact info, search telefonního adresáře).

Doporučuje se zřídit všechny uživatele před nebo na začátku projektu. To zahrnuje uživatele, kteří stále používají Unified CM pro svou volací platformu nezávislou na svém volajícím zařízení (IP telefon, Jabber,). Jakmile budou uživatelé migrováni na (a/nebo na), aktualizujete jejich licence, abyste povolili služby, které potřebují. Zřízení všech podnikových volajících uživatelů před zahájením přechodu umožňuje uživateli, který přešel do nebo, vyhledat v adresáři podnikového volajícího uživatele, který je stále na Jabberu a/nebo zapnutém. Tím je zajištěno, že přechodovaní uživatelé mohou najít kontaktní informace jakéhokoli jiného uživatele a zavolat jim pomocí vyhledávání adresáře.

Vyhledávání v adres áři obrázků ukazuje příklad uživatele, který hledá jiného uživatele. Výsledky vyhledávání zobrazují kontaktní informace uživatele a mohou být pro uživatele, který je stále na Jabberu, nebo pro uživatele, který přešel na a/nebo.

Vyhledávání v adresáři aplikace Webex

Dále určete, na kterého ze stávajících místních volajících uživatelů bude přechod. Pokud dojde k přechodu všech nebo velkého počtu uživatelů, doporučuje se přesunout uživatele do skupin, aby bylo zajištěno, že projektový tým, pracovníci IT a pracovníci podpory budou schopni zvlád nout přechod a případné problémy, které mohou nastat. Měli byste také vyčlenit nějaký čas na poskyt nutí počátečních informací a školení k přípravě uživatelů na tento přechod. Seskupování přechodu uživatelů lze provádět na základě různých kritérií, včetně umístění nebo webu, ke kterému jsou uživatelé přiřazeni, oddělení uživatelů nebo dokonce typy uživatelů (znalostní pracovníci, vedoucí pracovníci, mobilní pracovníci atd.).

Pokud jsou například uživatelé v nasazení rozděleni na tři hlavní lokality, New York (NYC), San Francisco (SFC) a Research Triangle Park (RTP), plán přechodu uživatelů může vypadat jako plán uvedený v tabulce přechodu uživatele podle tabulky.
Tabulka 4. Plán přechodu uživatele podle webu
Uživatelská stránka/ umístění Informace před přechodem a školení Přechodné období Podpora po přechodu
NYC (1 525 uživatelů) Týden 1. dubna 15. dubna — 27. dubna Týden od 29. dubna
SFO (1 600 uživatelů) Týden od 6. května 20. května — 31. května Týden 3. června
RTP (1 275 uživatelů) Týden 3. června 17. června — 28. června Týden 1. července

Dalším důležitým faktorem je přechod uživatelů, kteří mají mezi sebou závislosti. To může zahrnovat, ale není omezeno na následující:

Monitorování BLF

Stejný lovecký pilot/skupina

Sdílet řádky

Část stejné skupiny pro vyzvednutí hovorů

Používání stejných čísel parkovacích míst

Interkom

Admin/Exec.

Konfiguraci můžete zkontrolovat (grafické rozhraní nebo export) nebo pomocí nástroje Migration Insights identifikovat skupiny uživatelů s těmito závislostmi.

Tabulka 4. Plán přechodu uživatele podle webu
Uživatelská stránka/ umístění	Informace před přechodem a školení	Přechodné období	Podpora po přechodu
NYC (1 525 uživatelů)	Týden 1. dubna	15. dubna — 27. dubna	Týden od 29. dubna
SFO (1 600 uživatelů)	Týden od 6. května	20. května — 31. května	Týden 3. června
RTP (1 275 uživatelů)	Týden 3. června	17. června — 28. června	Týden 1. července

Připojení PSTN

může přistupovat k PSTN třemi způsoby: plány volání Cisco, Cloud connect for (dříve Cloud Connected PSTN) a místní PSTN (místní brána). Jedno umístění, jak je definováno v rámci možnosti PSTN, však lze přiřadit pouze jedné možnosti PSTN.

Místní síť PSTN s lokální bránou (LGW) je nezbytnou součástí strategie přechodu. Poskytuje konektivitu mezi místním nasazením a/nebo PSTN a platformou. podporuje jak Cisco, tak certifikované hraniční řadiče relací (SBC) třetích stran, které lze použít jako místní bránu. Nejnovější seznam podporovaných SBC najdete v části Seznam podporovaných SB C.

podporuje až 250 souběžných hovorů z jedné místní brány založené na registraci a více než 250 souběžných volání z jedné místní brány založené na certifikátu. Místní brány založené na certifikátech mohou podporovat až 6500 souběžných hovorů, ale to je založeno na typu připojení, které musí místní brána (Over-the-Top vs. interconnect peering) a modelu SBC, na kterém je místní brána nasazena. Tyto limity jsou v podstatě výchozím limitem počtu jak pro volání PSTN založené na místní bráně, tak pro volání mezi lokalitami a koncovými body. Další informace naleznete v tématu Začínáme s místní bránou.

Jakékoli hovory překračující tento limit jsou odmítnuty s 403 Forbidden. Hlasový příkaz Zobrazit aktivní volání lze spustit na místní bráně v libovolné instanci, aby se urč il celkový počet aktivních hovorů.

Špatné síťové podmínky mezi místní bránou a přístupovým SBC mohou omezit výkon signalizačního spojení, což vede k ještě nižšímu limitu sou běžných hovorů. Jednosměrná latence mezi lokální bránou a datovým centrem by neměla přesáhnout 100 ms a chvění by mělo být menší než 10 ms, zatímco ztráta paketů je menší než 0,5%.

Funkce a využití funkcí

Při posuzování aktuálního prostředí je důležité identifikovat a zkontrolovat, které funkce jsou nakonfigurovány. Kromě toho je důležité porozumět využití funkcí, abyste mohli (znovu) definovat své obchodní a technické požadavky pro vaše nasazení.

Chcete-li zjistit, které funkce jsou nakonfigurovány, analyzujte konfiguraci. Jedná se o všechna statická data, která jsou nastavena, když je v systému nakonfiguro vána funkce nebo nastavení. K dokončení této analýzy lze použít následující možnosti:

Zkontrolujte konfiguraci v administrátorském GUI

export konfigurace - hromadný export nebo AXL

nástroj pro přehledy migrace (doporučeno)

Nástroje pro partnery třetích stran Cisco (doporučeno).

Pro efektivní analýzu využití funkcí je nezbytné prozkoumat dynamická systémová data, jako je využití, registrace a aktivita hovorů. Různé analytické nástroje a řídicí panely poskytují přehled o těchto metrikách a umožňují komplexní pochopení výkonu a kapacity systému, což podporuje informované rozhodování během migrace a optimalizace. K dokončení tohoto typu analýzy lze použít následující možnosti:

Přehled nezpracovaných záznamů CDR

Přehled údajů Unified CM RTMT

Nástroj Migration Insights využívající data CDR

Recenze analytiky UC připojených k cloudu v

Hlasitost hovoru

Registrované koncové body

(CAC) lokality

Využití kufru.

Nástroje pro partnery třetích stran Cisco.

Společnost Cisco doporučuje začít s nástrojem Webex Control Hub Migration Insights pro tuto analýzu. Importujete exportní soubor.TAR a soubory Unified CM CDR (volitelné, ale nutné pro analýzu využití prvků) do nástroje. Nástroj vygeneruje následující zprávy založené na CSV , které lze použít k zahájení analýzy:

Tabulka 5. Zprávy generované ze Unified CM souboru.tar
Název zprávy
Popis zprávy
ImportedDataBulk.csv
Všichni uživatelé a zařízení z Unified CM dat
DeviceEligibility.csv
Identifikuje zařízení způsobilá k migraci Webex Calling (IP telefony, zařízení Room OS, ATA a třetí strany)
DevicePoolNumbers.txt
Seznam všech čísel v určitém fondu zařízení
HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv
Podrobnosti o zařízeních a uživatelích, které by měly být migrovány společně na základě sdílených linek, loveckého pilota, fronty hovorů, parkování hovorů a konfigurace skupiny pro vyzvednutí hovorů
HuntGroupMigrationInsight.csv
Podrobné informace o přiřazených lovec kých liniích, skupinách čar a přidružených agentech
SharedlineGroupMigrationReport.csv
Přehled sdílení telefonních čísel (adresářových čísel) mezi uživateli

Tabulka 6. Zprávy generované ze soubor Unified CM ů.tar a CDR. gzip
Název zprávy
Popis zprávy
FeatureUsageBasedDeviceEligibilityReport.csv
Informace o způsobilosti pro migraci zařízení na základě využití funkce
FeatureUsageWithLastUsageDateReport.csv
Počet využití pro počet volaných pilotů a fronty volání spolu s datem posledního použití
UserWorkspaceLastUsage.csv
Datum posledního použití pro uživatele a pracovní prostory pro softwarové klienty i pevné telefony
DIDUsageReport.csv
Využití DID pro přiřazené i nepřiřazené DID

Další podrobnosti o přehledech Migration Insights najdete v tématu Přehled migrace .

Pokud potřebujete další informace o funkcích a využití po přečtení informací v přehledech Migration Insights, společnost Cisco doporučuje zvážit jeden z nástrojů pro migraci partnerů třetích stran společnosti Cisco a/nebo zkontrolovat konfigurace v grafickém rozhraní nebo v datech exportu konfigurací.

Tabulka 5. Zprávy generované ze Unified CM souboru.tar
Název zprávy Popis zprávy
ImportedDataBulk.csv Všichni uživatelé a zařízení z Unified CM dat
DeviceEligibility.csv Identifikuje zařízení způsobilá k migraci Webex Calling (IP telefony, zařízení Room OS, ATA a třetí strany)
DevicePoolNumbers.txt Seznam všech čísel v určitém fondu zařízení
HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv Podrobnosti o zařízeních a uživatelích, které by měly být migrovány společně na základě sdílených linek, loveckého pilota, fronty hovorů, parkování hovorů a konfigurace skupiny pro vyzvednutí hovorů
HuntGroupMigrationInsight.csv Podrobné informace o přiřazených lovec kých liniích, skupinách čar a přidružených agentech
SharedlineGroupMigrationReport.csv Přehled sdílení telefonních čísel (adresářových čísel) mezi uživateli

Tabulka 6. Zprávy generované ze soubor Unified CM ů.tar a CDR. gzip
Název zprávy Popis zprávy
FeatureUsageBasedDeviceEligibilityReport.csv Informace o způsobilosti pro migraci zařízení na základě využití funkce
FeatureUsageWithLastUsageDateReport.csv Počet využití pro počet volaných pilotů a fronty volání spolu s datem posledního použití
UserWorkspaceLastUsage.csv Datum posledního použití pro uživatele a pracovní prostory pro softwarové klienty i pevné telefony
DIDUsageReport.csv Využití DID pro přiřazené i nepřiřazené DID

Integrace společnosti Cisco: Unity Connection UCCX UCCE

Hlasová schránka je nedílnou součástí nabídky a nativně zabudovaná do řešení. nelze integrovat s místním řešením hlasové schránky, jako je Unity Connection nebo Unity Connection Express. Dále, neexistuje žádný nativní způsob, jak migrovat stávající hlasové zprávy nebo pozdravy připojení Unity na nativní službu hlasové schránky dostupné u. Některé nástroje pro migraci partnerů třetích stran společnosti Cisco mají možnosti migr ace některých těchto dat. Další informace o hlasové schránce pro, viz Konfigurace a správa nastavení hlasové schránky pro uživatele. Webex Calling

podporuje také sdílené hlasové schránky a faxové poštovní schránky. Další informace naleznete v tématu Správa sdílené hlasové schránky a příchozí faxové schránky pro. Webex Calling

má vestavěnou funkci Auto Attendant, která je součástí základní platformy. Tato funkce umožňuje přechod obsluhy hovorů vašeho Unity Connection a funkce automatické obsluhy . Nástroj Řídicího centra Migrace funkcí z Unified CM podporuje migraci konfigurací připojení Unity na automatické obsluhy. Další informace o používání tohoto nástroje naleznete v tématu Migrace zařízení a funkcí z Unified CM doWebex Calling.

Nahrávání hovorů

obsahuje dvě možnosti pro nahrávání hovorů bez dalších nákladů.

Nahrávání hovorů Webex

Dubber Go nahrávání (nabídka partnera) - integrace mezi a dubber, kde jsou všechna nahraná média bezpečně uložena v cloudu.

zahrnutá tabulka možností nahrávání zdůrazňuje některé klíčové funkce dvou možností nahrávání hovorů, které jsou k dispozici bez dalších nákladů.

Tabulka 7. zahrnuté možnosti nahrávání
Webex Double Go

Dostupné všem uživatelům Dostupné všem uživatelům

Neomezené nahrávky Neomezené nahrávky

Doba uchovávání 1 roč* 30denní retenční doba

100 GB úložiště na organizaci -

Pracovníci pro dodržování předpisů mohou přistupovat k záznamům hovorů a spravovat je -

API pro správu nahrávek -

Správci mohou konfigurovat a spravovat přístup uživatelů k nahrávkám hovorů
Uživatelé mohou spravovat své vlastní nahrávky pomocí User Hub a/nebo aplikace Webex.
Pouze uživatelé mohou přistupovat a spravovat své nahrávky
Z jejich dubberového portálu.

Pokud vaše organizace vyžaduje další možnosti nahrávání, jako je nahrávání hovorů v souladu s předpisy, delší doby uchovávání, větší úložiště, analýza umělé inteligence a/nebo přístup správce, existují placené nabídky nebo doplňky od Cisco i poskytovatelů nahrávání třetích stran. Další informace o poskytovatelích nahrávání, konfiguracích a doplňkových partnerských službách naleznete v tématu S práva nahrávání hovorů pro Webex Calling.

Tabulka 7. zahrnuté možnosti nahrávání
Webex	Double Go
Dostupné všem uživatelům	Dostupné všem uživatelům
Neomezené nahrávky	Neomezené nahrávky
Doba uchovávání 1 roč*	30denní retenční doba
100 GB úložiště na organizaci	-
Pracovníci pro dodržování předpisů mohou přistupovat k záznamům hovorů a spravovat je	-
API pro správu nahrávek	-
Správci mohou konfigurovat a spravovat přístup uživatelů k nahrávkám hovorů Uživatelé mohou spravovat své vlastní nahrávky pomocí User Hub a/nebo aplikace Webex.	Pouze uživatelé mohou přistupovat a spravovat své nahrávky Z jejich dubberového portálu.

Integrace třetích stran

podporuje celou řadu integrací třetích ^stran, mimo jiné včetně SBC pro místní brány, IP telefony, interkomové telefony, reproduktory/pagery, ATA atd. Kromě těchto zařízení třetích stran ^{Webex Callingpodporuje} různá řešení třetích stran ^pro zákaznickou podporu, analýzu, nahrávání, fakturaci atd. Další informace o řešen ích ^třetích stran naleznete v tématu Webex App Hub.

Plán

Plán projektu na vysoké úrovni

Migrační cesta - jeden nebo dva kroky?

Možnost 1: Jednostupňová migrace uživatele

Možnost 2: Migrace uživatele ve dvou krocích

Krok 1

Krok 2

Plán projektu na vysoké úrovni

Při vytváření plánu projektu na vysoké úrovni pro migraci z do, je nezbytné stanovit jasné fáze a milníky, které jsou v souladu s obchodními cíli i technickými požadavky. Plán by měl začít komplexní fází hodnocení, včetně shromažďování podrobných technických a obchodních požadavků, jakož i identifikace zúčastněných stran a definování kritérií úspěchu. Mezi klíčové aspekty patří alokace zdrojů, odhad časové osy, řízení rizik a komunikační strategie, které zajistí, že všechny strany budou během migrace informovány a zapojeny. Plán by navíc měl zahrnovat kontrolní body ověření, jako je pilotní testování a postupné zavádění, aby se minimalizovalo narušení a umožnilo úpravy na základě zpětné vazby.

Příklady prvků, které mají být zahrnuty do plánu projektu, jsou:

Definování rozsahu migrace (např. ke kterým uživatelům, zařízením a funkcím dojde k přechodu)

Plánování školení pro koncové uživatele a týmy podpory

koordinace hodnocení připravenosti sítě a

Plánování aktivit s možností nouze. Je také důležité integrovat kontroly dodržování předpisů a zabezpečení, jakož i fáze podpory a optimalizace po migraci.

Strukturováním plánu projektu s těmito úvahami mohou organizace lépe řídit složitost, snižovat rizika a dosáhnout plynulejšího přechodu na.

Migrační cesta - jeden nebo dva kroky?

vyžaduje, aby uživatelé používali pro volání měkkého klienta. Proto, pokud někteří uživatelé stále používají, máte dvě možnosti, kdy je můžete přesunout do. Můžete provést migraci uživatele v jednom kroku nebo migraci uživatele ve dvou krocích.

Možnost 1: Jednostupňová migrace uživatele

V jednom kroku migrace, uživatelé přecházejí z do současně s přechodem z Unified CM do. Tato možnost je obvykle určena zákazníkům s malým počtem uživatelů k migraci a mohou spravovat přesun softwarového klienta uživatele i služby volání současně. Obrázek, na který migruje současně služba volání uživatele, softwarový klient a telefon níže, zdůrazňuje tento typ migrace. S touto volbou bude uživatel mít dokončeno následující současně:

Volací služby byly přesunuty z do

Telefonní čísla a rozšíření přesunuty z do

Softwarový klient přešel z Jabberu na - zaregistruje se do

Registrace telefonu se přesunula z do.

Služba volání uživatele, softwarový klient a telefon migrují současně

Stále se může jednat o postupnou migraci, kdy se skupiny uživatelů přesouvají v různých časech, ale když je každý uživatel přesunut, všechny tyto změny probíhají současně.

Možnost 2: Migrace uživatele ve dvou krocích

Druhým přístupem je migrace ve dvou krocích. V kroku 1, uživatelé jsou převedeni z na služby, ale zůstávají zapnuti pro volání. Poté v kroku 2, uživatelé jsou přesunuti z Unified CM do. Tato možnost se doporučuje větším zákazníkům, kteří spravují změny koncového uživatele a chtějí oddělit změnu měkkého klienta uživatele od změny služby volání. Následující obrázek Migrace měkkého klienta; poté migrujte službu volání, softwarového klienta a telefonu Webex Calling níže zvýrazňuje tento typ migrace.

Krok 1

Měkký klient přešel z na - zaregistruje se do.

Krok 2

Volací služby se přesunuly z do.

Telefonní čísla a rozšíření přesunuty z do.

registrace přesunuta z do.

Registrace telefonu se přesunula z do.

Migrujte softwarového klienta; poté migrujte volací službu, softwarového klienta a telefon na Webex Calling

Stále se může jednat o postupnou migraci, kdy se skupiny uživatelů přesouvají v různých časech v obou krocích.

Volba, kterou vyberete, závisí na tom, jak chcete spravovat přechod uživatelů na a. Doporučuje se postupovat v krocích (možnost 2). To vám umožní minimalizovat změny koncového uživatele najednou a rozdělit úsilí mezi různé části projektu. Pokud však dáváte přednost tomu, aby uživatelé byli ovlivněni pouze jednou, pak je použití možnosti 1 také platné.

Když se podíváme na doporučenou cestu (možnost 1), obrázek mapy přechodu na vysoké úrovni aplikace Jabber na Webex níže ukazuje přecho d na vysoké úrovni pro krok 1.

Mapa přechodu na vysoké úrovni aplikace Jabber na Webex

V tomto kroku jsou uživatelé převedeni z Jabberu na všechny své volací služby. nicméně, volající platforma je stále Unified CM a bude registrovat své volací služby. Jak je vidět na obrázku přechodu na vysoké úrovni aplikace Jabber na Webex, místní infrastruktura se nemění a funguje stejně jako Jabber. Jedinou změnou je, že vyžaduje připojení.

Další informace o tomto přechodu naleznete v tématu Průvodce mapou přechodu a nasazením Jabber na Webex v části Klient na stránce Přecho d spolupráce.

Unified CMWebex Callingna obrázek přechodové mapy na vysoké úrovni je přechod na vysoké úrovni z na. Toto je krok 2 doporučené cesty.

Unified CMna mapu přecho Webex Calling du na vysoké úrovni

Pokud se rozhodnete použít jednokrokový přístup, platí to také.

V tomto kroku jsou uživatelé přecházeni ve skupinách. V tomto okamžiku uživatelé začnou používat pro své volací služby, registraci volání a registraci IP telefonu.

Protože se uživatelé pohybují ve skupinách, Enterprise uživatelé budou během přechodu rozděleni mezi dvě volající platformy. Fáze 1 Unified CMna obrázku přecho Webex Calling dové mapy na vysoké úrovni zobrazuje tento stav. Během této fáze je nutné plánování, jak spravovat hovory mezi uživateli na obou platformách a jak budou směrovány hovory PSTN. Pokaždé, když dojde k přechodu na skupinu uživatelů, budou vyžadovány aktualizace telefonického tarifu a směrování hovorů a místní brány.

Po přechodu na všechny uživatele, softwarové klienty a zařízení (fáze 2) lze veškerou místní infrastrukturu UC odebrat a vyřadit z provozu.

Návrh

Výběr regionu

Lokality

PSTN

Číselný plán

Místní vytáčecí plán v

číselný plán

Nahrávání

1. Výběr poskytovatele nahrávání hovorů

2. Výběr regionu

Tísňové volání

Licencování

Ruční přiřazení přes

Šablony automatického přiřazení licencí

Hromadné přiřazení prostřednictvím šablony CSV

Přiřazení na základě rozhraní API

Požadavky na licenci

Zřizování uživatelů

Skupiny uživatelů

Doporučený přístup při migraci z do

Navrhování skupin uživatelů

Jednotné přihlášení (SSO)

Podpora více IdP

1. Fúze a akvizice

2. Více nezávislých IT oddělení

3. Různé skupiny uživatelů nebo domény

4. Podpora různých autentizačních protokolů

5. Vylepšené zabezpečení a dodržování předpisů

6. Zjednodušené uživatelské prostředí

Duo MFA s SSO pro

Vlastnosti

Automatická obsluha

Volejte Park

Vyzvednutí hovorů

Fronta hovorů

Huntská skupina

Provozní režimy

Skupina stránkování

nahrávky

Dosah jednoho čísla

Skupina hlasové schránky

Výběr regionu

je dostupný po celém světě a je dodáván z redundantních datových center ve více regionech: USA (Dallas, Chicago), Kanada (Vancouver, Toronto), Evropa (Frankfurt, Amsterdam), Velká Británie (Londýn, Manchester), Austrálie (Melbourne, Sydney), Japonsko (Tokio, Osaka), Saúdská Arábie (Rijád, Džidda) a Indie (Bombaj, Chennai). Mediální POP poskytují mediální služby pro optimalizaci doby zpá teční cesty médií. Singapurské datové centrum se například používá k optimalizaci časů zpá teční cesty médií pro zákazníky v asijských zemích, kde mohou být zpáteční časy do Austrálie nebo Japonska neoptimální. Datová centra jsou propojená multigigabitovou a plně redundantní páteří. Obrázek globálně distribuovaných datových center ukazuje přehled všech datových center. Nejnovější seznam dostupných datových center najdete v části Umístění datových center pro Webex Calling.

Globálně distribuovaná datová centra

Každý zákazník je zřizován v jedné z instancí. Veškeré informace o zřizování daného zákazníka jsou uloženy v této instanci a signalizace SIP všech koncových bodů a místních bran zřízených pro tohoto zákazníka je vázána na instanci, ve které je zákazník zřizován. Protože je těžké změnit počáteční výběr regionu, je důležité zvážit všechny relevantní faktory jako součást rozhodovacího procesu vedoucího k výběru regionu. Aby se zabránilo nadměrnému zpoždění zpáteční signalizace, je důležité rozhodnout se na začátku procesu přechodu, která instance by měla být použita. Společnost Cisco doporučuje vybrat instanci, která poskytuje nejnižší doby signalizace zpáteční cesty pro největší počet uživatelů v rámci nasazení.

Dostupnost v zemi naleznete v části Kde je Webex k dispozici? .

Lokality

Pro přípravu na přidělování umístění je třeba shromáždit požadované informace pro všechna cílová umístění migrace. Informace potřebné pro každé místo jsou shrnuty v Informace, které je třeba zachytit pro každé místo.
Tabulka 1. Informace, které je třeba zachytit pro každé místo
Informace Komentář
Rozsah (y) rozšíření Každé umístění může mít rozšíření začínající různými číslicemi. Jedna číslice musí být ušetřena pro číslici řízení mezi místy (například 8) a jedna pro číslici řízení PSTN (například 9). Žádný rozsah rozšíření nemůže začínat žádnou z těchto dvou číslic.
Všechny rozsahy rozšíření všech umístění musí mít stejnou délku.
Rozsah (y) DID -
Číslice řízení PSTN -
Kód webu Všechny kódy stránek všech míst musí být jedinečné a mít stejnou délku.
Hlavní číslo Při vytváření umístění je třeba zřídit dva DID. Jedno jako hlavní číslo (například přiřazené službě automatické obsluhy) a jedno pro portál hlasové sch ránky.
Zajistěte jeden DID pro číslo hlasové schránky.
Číslo hlasové schránky
Počet licencí Požadované licence podle typu včetně Standard, Professional, Workspace, Route List, Outbound Calling Plan.
Souběžné hovory v rušné době Součet souběžných hovorů mezi zařízeními a mezi zařízeními a místní bránou (PSTN a volání do zařízení). Potřebné k určení požadované šířky pásma přístupu k internetu.
Země -
Časové pásmo -
Jazyk -
Kontakt (jméno, telefon, e-mail) -
Adresa (ulice, město, stát, PSČ) -
Fyzické odeslané umístění záchranných služeb pro koncové body Místo odeslání zařízení používané pro tísňové volání obecně zahrnuje následující: adresa budovy, adresa budovy+číslo patra, adresa budovy+číslo apartmá nebo adresa budovy + číslo podlaží + číslo kanceláře/kubické číslo.
Jedinečné fyzické umístění v síti na zařízení pro tísňové služby Fyzické umístění sítě pro tísňové volání obecně zahrnuje následující: přepínač/switchport pro kabelová zařízení, identifikátory základní sady služeb (AP) bezdrátového přístupového bodu (BSSID) pro bezdrátově připojená zařízení a/nebo místní podsítě IP pro koncová zařízení.

PSTN

Při navrhování nasazení mají zákazníci tři primární možnosti připojení PSTN: Cisco C alling Plans (cloudová služba PSTN spravovaná společností Cisco), Cloud Connec ted PSTN Providers (CCPP, kde poskytovatelé poskytují službu PSTN prostřednictvím cloudu) a místní PSTN (kde místní brány propojují podnikovou síť s PSTN). Se zavedením trunkingu PSTN pro hybridní nasazení (Další informace viz trunking PSTN pro hybridní nasazení při trunkování PSTN) získávají organizace Webex Calling další flexibilitu ve svém přístupu k migr aci. Tato funkce umožňuje zákazníkům přesunout své PSTN na CCPP na začátku cesty přechodu a začít přecházet na cloudové PSTN pro uživatele, přičemž využívá CCPP k udržení služby PSTN pro uživatele, kteří zůstávají na Cisco během postupné migrace.

Tento hybridní přístup umožňuje organizacím přesunout vybrané skupiny uživatelů do cloudu jako první, aniž by okamžitě přepracovaly celé své telefonní prostředí. Zavádí však další složitost a riziko, zejména pokud jde o přizpůsobení stávající logiky směrování hovorů na podporu nové architektury. Interoperabil ita se staršími aplikacemi, jako jsou faxové servery, kontaktní centra nebo stránkovací systémy, také vyžaduje pečlivé zvážení. Klíčové technické výzvy mohou zahrnovat zajištění bezproblémového vyjednávání kodeků typu end-to-end a signalizace DTMF (Dual-Tone Multi-Frequency) napříč smíšeným prostředím, stejně jako ověření kompatibility se specializovanými telefonními funkcemi. Správ né plánování a testování jsou nezbytné pro minimalizaci narušení a udržení spolehlivých hlasových služeb v průběhu procesu migrace. Kromě toho jsou důležité obchodní aspekty, protože hybridní trunking vyžaduje licenci pro použití, která je založena na počtu souběžných hovorů mezi místním prostředím a poskytovatelem služby PSTN (CCPP) připojeným k cloudu.

Alternativně, organizace se mohou rozhodnout zachovat své místní připojení PSTN po celou dobu přechodové fáze. V tomto scénáři lze migraci na CCPP provést dvěma způsoby: jako jeden koordinovaný přechod pro všechny uživatele a umístění po dokončení migrace, nebo přírůstkově, přičemž migrace PSTN probíhá na základě jednotlivých lokalit při přesunu uživatelů. Tento přístup může pomoci zefektivnit koexistenci a zachovat kontinuitu pro starší integrace, ale přináší několik provozních složitostí. Mezi ně patří výzvy související s přenosem čísel, jako je potřeba přesné koordinace objednávek číselných portů, potenciální zpoždění, a omezení uložená poskytovatelem, jako je omezení počtu souběžných požadavků na port nebo omezení přenosu podmnožin velkých číselných bloků. Organizace musí pečlivě naplánovat svou strategii přechodu na PSTN s přihlédnutím k těmto logistickým aspektům, aby se zabránilo přerušení služeb a zajistily hladkou migraci.

Migrace na CCCP na začátku vs. zachování místního PSTN

Obrázek Migrace na CCCP na začátku vs. zachování místního PSTN ukazuje dvě možnosti migrace PSTN vysvětlené výše. Obrázek vlevo ukazuje scénář, kdy všichni místní uživatelé a aplikace Webex Calling využívají služby PSTN připojené ke cloudu prostřednictvím místního kmene a místní brány připojující místní bránu, zatímco obrázek vpravo ukazuje scénář, kdy stávající místní PSTN zůstane na svém místě a uživatelé používají místní PSTN prostřednictvím připojení místní brány mezi místními služ bami a. Během přechodu lze přepnout umístění pomocí Cloud Connected PSTN.

V obou scénářích volání mezi místním a uživatelem využívají připojení místní brány. Spojení mezi místními a místními zařízeními musí být navrženo a dimenzováno odpovídajícím způsobem na základě očekávaného počtu souběžných ho vorů a požadované redundance.

Číselný plán

Aby bylo dosaženo bezproblémové interoperability mezi obdobím migrace a během něj, musí být vyvinuta a implementována komplexní architektura číselného plánu na obou platformách. Tento návrh číselného plánu s dvěma platformami zajišťuje konzistentní směrování hovorů, překlad čísel a transparentnost funkcí, což uživatelům v obou systémech umožňuje komunikovat bez zhoršení služeb nebo narušení uživatelské zkušenosti během fáze koexistence.

Místní vytáčecí plán v

Během přechodu, aby umožnila koexistenci zařízení registro Unified CM vaných na a na podnikovém číselném plánu je třeba změnit tak, aby bylo možné splnit alespoň následující požadavky:

+E.164 vytáčení z do

Rozšířená volba z do (uvnitř pracoviště, ale také mezi pracovišti, pokud jsou rozsahy rozšíření jedinečné)

Zkrácená volba mezi místy z do

Vynucené vytáčení přes síť z do

Zpětné volání z adresáře zmeškaných hovorů do cílových míst

Volání PSTN z PSTN, pokud se během přechodu používá místní PSTN

Volání PSTN z do if během přechodu se používá trunking PSTN pro hybridní nasazení k zajištění přístupu PSTN místním uživatelům prostřednictvím služby Cloud Connect pro

Vynucené připojení k síti od do

Rozšířená volba z do (mezi místy).

Pokud některý z výše uvedených návyků není podporován volací návyk před přechodem, například neexistuje žádný zkrácený zvyk vytáčení mezi místy, pak nemusí být nutně zaváděny během přechodu.

Číselný plán Osvědčené postupy znázorňuje osvědčené postupy pro vytáčecí plán, jak je popsáno v části Prefer ovaná architektura pro Cisco Collaboration 12.x Enterprise On-Premises Deployments, CVD. Mezi klíčové charakteristiky tohoto přístupu patří:

Jeden oddíl pro čísla adresářů+E.164

Směrování jádra založené na vzorcích tras +E.164

Normalizace všech volebních návyků na +E.164 pomocí překladových vzorů

Použití překladového vzoru volajícího dědičnost vyhledávacího prostoru (možnost Použít volající vyhledávací prostor původce nastaven ý na vzory překladu).

Osvědčené postupy pro vytáčecí plán

Například vytáčení PSTN (9+1+10D) ze zařízení v SJC zřízeném vyhledávacím prosto rem SJCinternational se nejprve přiřadí překladový vzor 9.1 [2-9] XX [2-9] XXXXXX, který normalizuje číslo volané strany na +E.164. Sekundární vyhledávání pak znovu použije stejný volající vyhledávací prostor SJCinternational (vyvolává dědičnost vyhledávacího prostoru) a řetězec +E.164 bude buď přiřazen číslem adresáře +E.164 v oddílu DN, nebo jedním ze vzorů trasy PSTN v oddílu USPSTNNational nebo SJCPSTNLocal. Zkrácené návyky vytáčení uvnitř a mezi místy jsou implementovány překlady v oddílu ES N a SJCTOE164. Zatímco oddíl ESN je globální oddíl (přístupný pro telefony ve všech umístěních), oddíl SJCTOE164 je přístupný pouze uživatelům v umístění SJC. To předpokládá překrývající se rozsahy rozšíření.

Prvním krokem k povolení volání z do je zajistit, aby cíle +E.164 byly odpovídajícím způsobem směrovány. Toho lze dosáhnout přidáním oddílu do číselného plánu, přidáním vzorů trasy +E.164 pro všechny cíle do tohoto oddílu a nakonec přidáním oddílu do všech volajících vyhledávacích prostorů představujících třídy služeb, které je třeba dosáhnout. Vytvoření vyhrazeného oddílu je nutné, aby bylo možné vytvořit diferencovanou třídu služeb pro volání pocházející z. Aby se zabránilo smyčkám volání, nemělo by mít vyhledávací prostor pro příchozí volání v kmeni z místní brány přístup k oddílu.

+E.164 směrování do Webex Calling

Jak je znázorněno na obrázku +E.164 směrování doWebex Calling, aby bylo možné směrování z do pro umístění s rozsahem +E.164 DID +1 221 555 2XXX a kódem lokality 121, je třeba do oddílu přidat urgentní vzor trasy odpovídající tomuto rozsahu+E.164.

Pokud není vyžadován žádný výběr místní brány pro konkrétní lokalitu, pak místo použití seznamu tras s místní skupinou tras jako cíle pro vzory tras ukazující na jednu skupinu tras lze zřídit s místní bránou jako jediným členem a poté vzory tras odkazují na jeden seznam tras s touto jedinou skupinou tras jako jedinou položkou.

Pro povolení zkrácené vytáčení mezi lokalitami je do oddílu přidán požadovaný vzor tras y 8121.2XXX. Pro lokality, které mají být převedeny na normalizační vzorec vytáčení 8121.2XXX, který normalizuje volbu ESN na +E. 164, již mohou existovat v oddílu ESN. V takovém případě se 8121.2XXX jeví jako nadbytečný, ale jakmile budou všechny DN příslušného umístění migrovány na normalizaci vytáčení 8121.2XXX, lze odstranit vzor překladu a pak vzor trasy 8121.2XXX umožní vytáčení ESN i pro uživatele pouze z rozšíření v daném rozsahu.

S těmito změnami číselného plánu lze volání do lokality uskutečňovat nejen vytočením zkráceného inter-site a +E.164. Také mezinárodní a národní vytáčení PSTN je možné, protože tyto návyky vytáčení jsou nejprve normalizovány na +E.164 prostřednictvím již existujících vzorů normalizace vytáčení a poté jsou směrovány porovnáním vzoru trasy +E.164 v oddílu.

Odpovídající vzor trasy +E.164 v rozsahu DID umístění lze zřídit, dokud jsou všechny DID stále hostovány zapnuté. Algoritmus párování vzorů nejlepší shody zajišťuje, že když je vytočeno číslo hostované na, bude číslo adresáře +E.164 zřízené lépe odpovídat než vzor trasy +E.164 se zástupným znakem ukazující na, takže hovory budou rozšířeny na linku zapnutou a ne odeslány.

číselný plán

Každému uživateli je přiděleno rozšíření a/nebo telefonní číslo +E.164. Délka rozšíření je pevné globální nastavení: všechna rozšíření v rozmístění mají stejnou délku. Rozšířené vytáčení lze použít mezi uživateli jak v rámci místa, tak mezi místy. Zkrácená volba mezi pobo čkami (druhý případ) funguje pouze v případě, že je vytočené rozšíření jedinečné.

Pokud je požadavkem zkrácené vytáčení mezi lokalitami, ale mezi rozšířeními přiřazenými v různých umístěních dochází k překrývání, je třeba vytvořit plán číslování specifický pro podnik tak, že rozšíření předponou přístupovým kódem a kódem webu. Další informace naleznete v tématu Preferovaná architektura pro místní nasazení Cisco Collaboration 15, Přehled návrhu dostupný na adrese Preferované architektury spolupráce společnosti Cisco.

Délka rozšíření, chování vytáčení mezi místy, délka předpony pro vytáčení mezi místy a číslice řízení v předponě směrování pro vytáčení mezi místy jsou nakonfigurovány v nastavení volací služby v:

Délka předpony směrování polohy: Délka předpony včetně číslice řízení. Vyžad uje se pouze v případě, že je třeba vytvořit plán podnikového číslování jako alternativní zkrácený podnikový zvyk vytáčení mezi lokalitami.

Číslice řízení v předponě směrování: Ř ídící číslice pro zkrácený podnikový zvyk vytá čení mezi místy. Je třeba se vyhnout překrývání s první číslicí libovolného místa a čísli c odchozího vytáčení polohy. Vyžad uje se pouze v případě, že je třeba vytvořit plán podnikového číslování jako alternativní zkrácený podnikový zvyk vytáčení mezi lokalitami.

Vnitřní délka prodlou žení: Standardní délka nástavců. Může být libovolná hodnota mezi dvěma a deseti.
Pokud je z místního řízení hovorů vyžadováno vytáčení nebo vytáčení pomocí podnikových významných čísel (kód řízení, kód lokality, rozšíření) a místní řízení hovorů odešle rozšíření jako ID volajícího, nezapomeňte také nastavit parametr Maximální neznámá délka rozšíření v části Směrování hovorů mezi místními místy a místními místy, aby bylo zajištěno, že volání z místního řízení hovorů lze správně klasifikovat jako místní hovory.

Povolit vytáčení z pobočky mezi místy: Přepnutím povolíte nebo zakážete vytáčení z pobočky mezi místy . Tato možnost by měla být povolena pouze v případě, že všechna rozšíření v organizaci jsou jedinečná. Pokud je tato možnost zakázána, je třeba mezi místy vytočit podniková významná čísla (kód řízení, kód webu, přípona) nebo telefonní čísla.

První tři parametry se používají hlavně k vytvoření číselného plánu pro telefony, aby se minimalizovaly mezimístné časové limity při použití off-hook vytáčení. Odchylky od těchto globálních nastavení jsou stále možné (Příklad - lze zřídit rozšíření s jinou délkou), ale v ovládacím centru se zobrazí varovná zpráva a vytáčení z telefonů může vyžadovat blokovanou volbu, aby se předešlo konfliktům v předinstalovaném číselném plánu.

Příklad číslování v tabulce Enterprise ukazuje příklad tří míst, kde jsou rozsahy rozšíření dvou míst, NYC a RTP, identické. Vytvoření schématu číslování podniků s číslicí řízení mezi pracovišti 8, následovaným třímístným kódem webu, a čtyřmístné rozšíření vytváří nepřekrývající se zkrácený zvyk vytáčení mezi weby.

Tabulka 2. Příklad podnikového číslování
Stránky Rozšiřující rozsah Kód webu Řada Enterprise

NYC 2XXX 202 8 202 2XXX

SFO 3XXX 203 8 203 3XXX

RTP 2XXX 204 8 204 2XXX

Aby byl umožněn hladký přechod, sada volacích návyků pro uživatele před a po přechodu na ideálně by měla být stejná. Pro přípravu na přechod pro každé místo je třeba zdokumentovat rozsa hy DID a rozsahy rozšíření (nebo zkrácené návyky vytáčení uvnitř místa). Na základě těchto informací je třeba vybrat číslici řízení mezi pracovišti.

Tabulka Rozsahy prodloužení pevných dé lek ukazuje příklad tří umístění a rozsahů prodloužení s pevnou délkou. Vzhledem k tomu, že je třeba se vyhnout překrývajícím se volacím návykům, je důležité se ujistit, že pro jakýkoli rozsah rozšíření se první číslice rozsahu neshoduje s číslicí řízení pro zkrácenou volbu mezi místy. Pokud je například 8 vybrána číslice řízení pro vytáčení mezi místy, pak žádný rozsah rozšíření na žádném místě nemůže začínat číslem 8. Typicky, rozšíření v daném místě odpovídají posledním číslicím DID přiřazených tomuto umístění. Aby se předešlo konfliktům, lze změnit první číslici rozšíření. Pokud jsou například DID v rozsahu +1 408 555 8XXX použity v určitém umístění, pak místo použití 8XXX jako rozšíření lze použít 7XXX pro rozšíření v daném webu

Tabulka 3. Rozsahy prodloužení pevných délek
Stránky Rozšiřující rozsah Rozšíření Kód webu Řada Enterprise

NYC 2XXX 2XXX 202 8 202 2XXX

SFO 8XXX 7XXX 203 8 203 7XXX

RTP 1XX 11XX 204 8 204 11XX

Sedmimístné číselné řetězce vytočené na zařízení pomocí amerického číselného plánu se překrývají se sedmimístným vzorem pro místní vytáčení v předinstalovaném americkém číselném plánu. Aby se zabránilo překrývání mezi jakýmikoli zvyky vytáčení v síti a mimo síť (PSTN), lze v tomto místě použít povinný externí přístupový kód. Pokud se stávající schéma číslování podniků a odpovídající zkrácené vytáčení mezi místy překrývají se vzory v národním číselníku, pak během přechodu na schéma číslování, aby se zabránilo překrývání, lze také změnit na delší nebo kratší formu. Nej jednodušší způsob, jak toho dosáhnout, je přidat další polstrovanou číslici do schématu číslování. Nové delší schéma vytáčení mezi weby musí přijmout pouze uživatelé, na které již migrovali. Uživatelé, kteří jsou stále zapnuti, mohou i nadále vytočit sedm číslic. V tomto případě musí být zapnutý podnikový vytáčecí plán zajistit, aby zkrácená sedmimístná volba z do byla převedena buď Unified CM na +E.164, nebo na zkrácený formát vytáčení nasazený na. To je třeba provést před odesláním hovoru na místní bránu.

Příklad tohoto přečíslování ukazuje sedmimístný přecho d tabulky. V tomto příkladu používá zkrácená volba mezi místy číslici řízení 8 následovaná dvoumístným kódem webu a čtyřmístným rozšířením. Aby se zabránilo sedmimístnému zkrácenému vytáčení mezi místy pro místa na, lze kódy stránek snadno změnit na tři číslice předponou libovolné polstrovací čí slice (8 v příkladu) k dvoumístným kódům stránek použitým v, takže volba mezi místy z telefonů používá číslici řízení 8 následovanou polstrovací číslicí 8, starý dvoumístný kód webu, a čtyřmístné rozšíření. Uživatelé si nemusí pamatovat nové kódy stránek; stačí si pamatovat použít 88 jako předponu pro vytáčení mezi weby místo 8 zapnuto.

Tabulka 4. Přechod sedmimístné volby

Stránky Rozšíření Kód webu Řada Enterprise Stránka óda Enterprise Angle

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

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

RTP 1XXX 24 8 24 11XX 824 8 824 11XX

Ve scénáři se zapnutými různými formáty podnikových čísel a pokud jsou podniková čísla prezentována jako informace volající strany pro volání z do (například volání ze zařízení bez DID), je důležité implementovat také mapování mezi různými formáty čísel pro informace volající strany, aby bylo zajištěno, že zpětné volání funguje. Tohoto mapování lze dosáhnout použitím vzoru transformace volající strany na kmeni mezi a místní bránou.

Nahrávání

Dobře navržené řešení nahrávání hovorů vyžaduje pečlivé zvážení několika klíčových konstrukčních prvků, aby bylo zajištěno, že je v souladu s organizačními cíli, regulačními požadavky a technickými omezeními. Dvě z nejdůležitějších rozhodnutí zahrnují výběr poskytovatele a výběr regionu, které může být nutné globálně přizpůsobit a přepsat na konkrétních místech, na základě obchodních potřeb.

1. Výběr poskytovatele nahrávání hovorů

Výběr vhodného poskytovatele nahrávání hovorů je zásadní pro splnění obchodních cílů a zajištění sladění funkcí v celé organizaci:

Výběr globálního poskytovatele: Organizace obvykle určují primárního poskytovatele nahrávání hovorů na globální úrovni, což zajišťuje konzistenci sady funkcí, dodržování předpisů a podpory ve všech lokalitách

Přepsání podle polohy: Ve scénářích, kdy konkrétní lokality nebo oblasti mají jedinečné obchodní potřeby nebo regulační požadavky, může být nutné přepsat globální výběr poskytovatele a určit alternativní poskytovatele pro tato místa. Tato flexibilita podporuje různé mandáty dodržování předpisů a místní provozní potřeby

Obchodní požadavky: Volba poskytovatele by měla být řízena posouzením faktorů podnikání, jako je dodržování předpisů (příklad — MiFID II, HIPAA), zajištění kvality, řešení sporů nebo potřeby školení

Dostupnost funkcí: Poskytovatelé by měli být vyhodnocováni na základě jejich schopnosti poskytovat požadované funkce, jako je monitorování v reálném čase, možnosti vyhledávání a přehrávání, šifrování, zásady uchovávání údajů, integrace s analytickými platformami a podpora různých typů hovorů (příchozí, odchozí, interní).

2. Výběr regionu

Určení oblasti, kde jsou záznamy hovorů uloženy a zpracovávány, je rozhodující pro dodržování předpisů a výkon:

Globální výběr regionu: Ve výchozím nastavení mohou organizace zvolit jednu oblast pro ukládání záznamů hovorů, aby se zjednodušila správa a správa

Přepsání oblastí podle polohy: Pokud to vyžadují zákony o pobytu dat nebo firemní zásady, může být nutné přepsat globální nastavení regionu pro konkrétní místa a zajistit, aby záznamy hovorů byly uloženy a zpracovávány v požadovaných geografických hranicích

Požadavky na umístění dat: Návrh musí zohledňovat mezinárodní a místní předpisy o ochraně údajů (jako je GDPR, CCPA nebo mandáty specifické pro jednotlivé země), které mohou určovat, kde a jak budou záznamy hovorů uchovávány.

Dalším kritickým aspektem, který je třeba řešit při plánování a návrhu řešení pro nahrávání hovorů, je odhad požadavků na úložiště. Přesné předpovídání potřeb úložiště je zásadní pro zajištění dostatečné kapacity pro podporu probíhajících obchodních operací, zachování souladu s předpisy a zabránění přerušení služeb.

Při určování očekávané poptávky po skladování je třeba vzít v úvahu několik klíčových parametrů:

Objem nahraných hovorů: Posoudit očekávaný počet hovorů, které budou zaznamenány v daném časovém intervalu (např. za den, týden nebo měsíc). To zahrnuje nejen externí hovory, ale také interní komunikaci, pokud to vyžaduje obchodní politika nebo regulační mandáty

Průměrná délka hovoru: Vy počítejte typickou délku zaznamenaných hovorů, protože delší hovory spotřebovávají více úložného prostoru. Odchylky v délce hovoru mezi různými odděleními nebo skupinami uživatelů by měly být také zohledněny do odhadu

Doba uchovávání: Definujte dobu, po kterou musí být záznamy uchovávány, což je často diktováno organizačními zásadami nebo externími předpisy (například standardy shody specifickými pro dané odvětví). Delší doba uchovávání zvýší celkové požadavky na skladování

Prognózy růstu: Zvažte očekávaný růst objemu hovorů nebo rozšíření rozsahu nahrávání, které může být důsledkem škálování podnikání, nových regulačních požadavků nebo začlenění dalších uživatelů nebo míst.

Důkladnou analýzou těchto parametrů mohou organizace vyvinout robustní strategii úložiště, která zajistí škálovatelnost, nákladovou efektivitu a dodržování předpisů pro jejich řešení pro nahrávání hovorů. Je také vhodné pravidelně kontrolovat a upravovat alokace úložiště, protože se vzorce využití v průběhu času vyvíjejí.

Tísňové volání

Požadavek na směrování tísňového volání do příslušného dispečerského střediska je požadavkem pro jakoukoli volací službu, která nabízí službu PSTN. S, směrování tísňových hovorů je nativní pro řešení a zahrnuje podporu pro všechna národní čísla tísňového volání v zemích, které podporují. Směrování tísňového volání je založeno na umístění definovaném uvnitř a metodě přístupu PSTN místa. Čísla tísňového volání jsou předdefinovaná a specifická pro zemi, ve které jsou uživatelé a zařízení nasazeni.

Existují dva způsoby doručování tísňových hovorů. K dispozici je základní služba směrování tísňového volání a rozšířená služba směrování tísňových hovorů. Základní služba směrování tísňových hovorů použije číslo vybrané správcem k identifikaci polohy a trasy volání k dosažení tísňových služeb. Pro základní tí sňové volání je cesta volání obvykle prostřednictvím možnosti PSTN zákazníka pro danou místu. má také rozšířené směrování tísňových hovorů navržené pro nasazení v USA a Kanadě, která mají požadavky na dodržování předpisů, které vyžadují použití celostátního poskytovatele k doručování tísňových hovorů do správného dispečerského centra .

Všichni zákazníci by měli nasadit alespoň základní konfiguraci tísňového volání. Základní tísňové volání vyžaduje, aby každému místu definovanému v aplikaci bylo přiřazeno alespoň jedno číslo +E.164 vlast něné zákazníkem. Pro základní tísňové volání bude každé místo definováno adresou ulice, na kterou jsou v případě nouze vyslány policejní, hasičské nebo záchranné služby. Ve většině případů je hlavní číslo místa nejlepší volbou pro reprezentaci fyzického umístění nouze. Přiřazení adresy číslu +E.164 je obvykle koordin ováno s poskytovatelem PSTN. Níže uvedené obrázky ukazují přiřazení hlavního čísla, které má být použito jako číslo tísňového volání pro umístění Richardson.

Umístění konfigurace ECBN

Ve většině situací, adresa budovy postačuje pro adresu odeslání místa. Pokud jsou však pro konkrétní uživatele nebo zařízení potřebné další podrobnosti o poloze , může správce použít stejný postup popsaný výše a přiřadit tato zařízení ke konkrétní adrese nebo přesnějšímu umístění uvnitř adresy (například podlaží nebo místnosti). Ve správě uživatelů v aplikaci, karta Volání umožňuje použití konkrétního čísla pro uživatele a jeho zařízení k získání konkrétní adresy odeslání. Následující obrázky ilustrují, jak lze zařízení přiřadit konkrétní číslo. Správce je odpovědný za to, aby číslo používané zařízením mělo přiřazenou správnou adresu odeslání. Při řazení adresy se obvykle provádí prostřednictvím poskytovatele PSTN tohoto umístění.

Konfigurace uživatele ECBN

Pro nasazení telefonie v USA, která musí poskytovat vylepšená řešení tísňového volání, používá pro směrování tísňových hovorů integrovanou Horizon Mobility společnosti RedSky. Při použití RedSky pro směrování hovorů musí správce zaregistrovat účet prostřednictvím společnosti Cisco a nakonfigurovat příslušné informace v Volání -> Nastavení služby, aby tuto funkci povolil. Jakmile je služba RedSky povolena na úrovni systému, správce povolí službu RedSky na každé úrovni umístění. Povolení rozšířeného tísňového volání v místě aktivuje službu pro všechna zařízení, která jsou k danému umístění přiřazena. Zařízení podporující rozšířené tísňové volání jsou telefony Cisco MPP, telefony Cisco PhoneOS a Cisco.

Existují dvě nastavení pro povolení rozšířeného tísňového volání na místě. Polo žka Povolit RedSky přijímat informace o síťovém připojení a testovací volání by měla být použita k ověření správnosti konfigurace RedSky pro mapování zařízení a infrastruktury. Toto nastavení také umožňuje provádět testovací hovory na 933 za účelem ověření polohy pomocí systému IVR společnosti RedSky k odečtení polohy volajícího. Ačkoli tento dokument nebude pokrývat konfiguraci RedSky pro sledování polohy, správce by měl VŽDY otestovat zjištění své polohy před aktivací tísňových hovorů pro směrování na RedSky. Jakmile bude testování dokončeno a ověřeno jako přesné, správce směruje hovory na RedSky přepnutím tísňových volání na RedSky. Tento přepínač nasměruje všechna tísňová volání z místa na RedSky pro doručení do záznamníku pro dané místo.

Nastavení rozšířeného tísňového volání platí také pro místní i externí klienty. V místním prostředí lze sledovat stejným způsobem, jakým jsou sledovány stolní telefony. Pokud je uživatel mimo místní prostředí, bude moci dynamicky nastavit své umístění přímo v rámci. Další informace o tísňovém volání naleznete v tématu Vylep šené tísňové volání pro.

Licencování

Existuje několik možností, jak uživatelům přiřadit licence.

Ruční přiřazení přes

Administrátoři ručně přiřazují licence jednotlivým uživatelům prostřednictvím rozhraní.

Správci mohou upravovat licence služeb pro jednotlivé uživatele a přiřadit licence pro volání přímo.

Šablony automatického přiřazení licencí

Pomocí šablon přiřazení licencí můžete automaticky přiřadit licence uživatelům na základě nastavení skupiny nebo organizace.

Automatické licencování lze provádět prostřednictvím synchronizace adresářů nebo ručních uživatelských aktualizací, ale uživatelé musí mít platné telefonní číslo ve formátu +E.164 a telefonní čísla musí existovat v určitém místě před zřizováním uživatele. Pokud nejsou splněny podmínky (např. neplatný formát telefonního čísla), licence nebudou přiřazeny.

Hromadné přiřazení prostřednictvím šablony CSV

Nahrajte soubor CSV s podrobnostmi o uživateli a přiřazením licencí, abyste přid ali nebo upravili více uživatelů najednou.

Import CSV podporuje přidání až 20 000 uživatelů a přiřazování licencí, ale licence vyžadují specifická pole, jako je telefonní číslo a přípona.

Přiřazení na základě rozhraní API

Pomocí rozhraní API můžete programově přiřadit licence a spravovat uživatele.

podporuje operace API pro správu uživatelů a licencí (People, SCIM 2.0 a Licences API), které lze využít pro automatizaci přiřazování licencí. Licenční API umožňuje současné přiřazování licencí, telefonních čísel a rozšíření.
Tabulka 5. Možnosti zřizování uživatelů - souhrn
Metoda přiřazení Klady Nevýhody
Manuální přes Jednoduché pro několik uživatelů.
Umožňuje přesnou a podrobnou kontrolu nad přiřaz ením licencí.
Není škálovatelný, časově náročný
Při ručním zadávání je náchylný k lidské chy bě.

Automatické šablony licencí Škálovatelný
Snižuje manuální chyby
Lze použít pro nové i stávající uživatele.
Vyžaduje platná telefonní čísla a místa.
Složitější nastavení
Vyžaduje také skupiny uživatelů na skupinu uživatelů s ekvivalentními licenčními požadavky.

Hromadné nahrávání CSV Efektivní pro velké uživatelské sady
Umožňuje současné přiřazování licencí, telefonních čísel a rozšíření.
Vyžaduje pečlivé formátování CSV
Potenciál chyb, pokud telefonní čísla nebo přípony chybí nebo jsou nesprávné.
Přiřazení na základě rozhraní API Automatizovatelný, flexibilní.
Umožňuje současné přiřazování licencí, telefonních čísel a rozšíření.
Vyžaduje vývoj a znalosti API.

Tabulka Možnosti zřizování uživatelů - souhrn shrnuje možnosti zřizování uživatelů a jejich klady a zápory. Tento přehled pomáhá vybrat nejlepší metodu přiřazení licencí na základě velikosti organizace zákazníka, možností automatizace a procesů a požadavků na zřizování uživatelů.

Pokud je to možné, společnost Cisco doporučuje přiřadit licence pro volání pomocí šablon licencí. To vyžaduje, aby pro každou skupinu uživatelů vyžadovala jedinečnou sadu licencí (Příklad - Standardní vs. Profesionální) existuje skupina s příslušným členstvím ve skupině. Jak je popsáno v oddílech Skup iny uživatelů, skupiny uživatelů lze definovat ručně nebo synchronizovat z podnikového adresáře. Kombinace obou přístupů je možná.

Uživatelé patřící do více skupin získávají licence ze všech přiřazení aplikovaných na všechny jejich skupiny. To umožňuje používat skupiny zabezpečení specifické pro licenci v podnikovém adresáři ke správě přiřazování licencí, kde je výsledné přiřazení uživatelské licence řízeno spojen ím členství ve skupině.

Další informace naleznete v tématu Nastavení automatického přiřazení licencí v Řídicím centru a Nastavení šablon automatického přiřazování licencí pro Webex Calling uživatele.

Požadavky na licenci

Tato část se zabývá pouze souvisejícími licencemi. Jiné typy licencí (Příklad - registrace zařízení Webex, zasílání zpráv, schůzky) nejsou zahrnuty. V rámci procesu návrhu je třeba stanovit licenční požadavky. Je třeba vypočítat počet licencí pro následující typy licencí:

Standard: počet jednotlivých uživatelů vyžadujících standardní telefonní funkce.

Profesionální: počet uživatelů a pracovních prostorů vyžadujících pokročilé funkce telefonování. Virtuální linky a skupinová hlasová schránka mají nárok na poměr 1:1 pro každou profesionální licenci. Proto ve vzácných případech, kdy počet požadovaných virtuálních linek nebo skupinových hlasových zpráv převyšuje počet uživatelů a pracovních prostorů vyžadujících pokročilé funkce telefonování, je třeba počítat s dalšími profesionálními licencemi.

Pracovní prostor pro společnou oblast: počet sdílených použití nebo míst ve společných prostor ách vyžadujících standardní možnosti volání.

Zákaznická pomoc: počet agentů a supervizorů vyžadujících funkce Customer Assist. Zákaznická pomoc zahrnuje licenci Professional.

Volání seznamu tras: počet požadovaných hovorů PSTN připojených ke cloudu mezi místními uživateli a/nebo místními specializovanými aplikacemi třetích stran.

Konzola obslu hy: počet uživatelů, kteří vyžadují přístup ke klientovi konzoly obsluhy.

Plán volání Cisco (plán odchozího volání): počet uživatelů, kteří vyžadují číslo PSTN a/nebo odchozí přístup k volání PSTN pro službu Cisco PSTN.

Pro profesionální pracovní prostory neexistuje žádný vyhrazený typ licence. Profesionální pracovní prostory spotřebovávají licenci Professional.

Pracovní prostory pouze na pracovišti typu hot-desk nabízejí hostitelskou službu hot-desking a tísňové volání z hostitele hot-desking a nevyžadují žádnou licenci. Další informace naleznete v tématu Přidání a správa zařízení pouze pro pracovní stůl.

Chcete-li určit požadovaný typ licence pro každého uživatele a pracovní prostor na základě potřebných funkcí, přečtěte si článek Funkce dostupné podle typu licence pro Webex Calling.

Chcete-li rozlišit mezi funkcemi nabízenými frontami volání v kombinaci s profesionální licencí na rozdíl od zákaznické asistence, viz Porov nání funkcí fronty ho Webex Calling vorů a zákaznické asistence.

Zřizování uživatelů

Při zřizování uživatelů ve Webexu je k dispozici několik možností, z nichž každá vyhovuje různým potřebám a prostředím organizace:

Ruční zřizování: Správci mohou přidávat a spravovat jednotlivé uživatele přímo uvnitř. Tato metoda je přímočará, ale nejvhodnější pro malé organizace nebo omezené změny uživatelů.

Hromadné zřizování prostřednictvím CSV: U větších uživatelských základen mohou správci hromadně importovat a aktualizovat uživatele nahráním souborů CSV do. To umožňuje efektivní správu až tisíců uživatelů najednou.

Možnosti synchronizace adresářů:
Adresářový konektor: Jedná se o automatický synchronizační nástroj používaný v Microsoft Active Directory prostředích. Synchronizuje uživatelské účty, skupiny a atributy na plánovaně (hodinově, denně nebo týdně). Podporuje nastavení více domén a více doménových struktur Active Directory a může synchronizovat obrázky profilů a objekty místnosti.

Aplikace průvodce Entra ID (Azure AD): Tato metoda je navržena pro organizace používající Microsoft Entra ID (Azure AD) a poskytuje automatickou synchronizaci uživatelských účtů a atributů téměř v reálném čase přímo z Entra ID do. Je plně spravován uvnitř a vyžaduje minimální nastavení.

Aplikace SCIM 2.0: V prostředích jiných než Microsoftu nebo jiných poskytovatelů identit, jako je Okta nebo Duo, umožňují synchronizační aplikace založené na SCIM automatické zřizování a deaktivaci uživatelů s mapováním atributů a synchronizací skupin.

Unified CMsynchronizace uživatelů: Tato možnost umožňuje vytvářet uživatelské účty založené na existujících koncových uživatelích synchronizací z do. To vyžaduje, aby v místních clusterech bylo spuštěno řešení Cloud Connected UC (CCUC). Obecně se však doporučuje synchronizovat uživatele z centralizovaného cloudového adresáře, jako je Entra ID, spíše než přímo z.

Zřizování API: Veřejná API (People, SCIM 2.0) lze použít k zřízení uživatelů. Hlavní výhodou používání rozhraní API je možnost integrovat zřizování uživatelů s jinými podnikovými systémy.
Tabulka 6. Možnosti zřizování uživatelů pro
Způsob poskytování Popis Klady Nevýhody
Manuál Vytvářet/spravujte uživatele jednotlivě v Jednoduché pro několik uživatelů; není potřeba žádná infrastruktura Není škálovatelný; časově náročné pro mnoho uživatelů
Hromadné (soubor CSV) Importujte/aktualizujte uživatele hromadně prostřednictvím CSV Efektivní pro skupiny; není nutné kódování Manuální příprava CSV; méně dynamické
Lidé a SCIM 2.0 API Programová správa uživatelů prostřednictvím rozhraní API Webex Flexibilní; podporuje automatizaci a integraci Vyžaduje rozvoj a infrastrukturu
Synchronizace adresářů Automatická synchronizace z aplikací AD, Entra ID, SCIM, Unified CM Automatizuje životní cyklus; podporuje filtrování a mapování Složitost nastavení: některé možnosti mají omezené funkce nebo vyžadují infrastrukturu
Tento přehled a tabulka odrážejí hlavní možnosti zřizování uživatelů, jejich výhody a omezení, které vám pomohou vybrat nejlepší přístup pro potřeby vaší organizace.

Skupiny uživatelů

Správa skupin uživatelů v aplikaci umožňuje správcům organizovat uživatele do skupin pro efektivní hromadnou správu licencí, nastavení a zdrojů. Skupiny pomáhají zjednodušit správu tím, že apli kují zásady, licence a šablony nastavení na více uživatelů současně, namísto správy uživatelů jednotlivě.

Správa skupin uživatelů nabízí několik výhod, včetně:

Zjednodušená správa: Spravujte licence, nastavení a zásady pro více uživatelů najednou.

Konzistence: Použijte jednotná nastavení a licence pro uživatele ve stejné skupině.

Škálovatelnost: Podporuje až 250 000 členů na skupinu.

Integrace: Synchronizujte skupiny z Microsoft Entra ID (Azure AD) nebo Active Directory pro automatizovanou správu uživatelů a skupin.

Flexibilita: Vytvářejte místní skupiny nebo synchronizujte skupiny zabezpečení; spravujte členství ve skupině ručně nebo prostřednictvím souborů CSV.

Přidělení zdrojů: Řízení přístupu k vloženým aplikacím a službám na základě členství ve skupině.

Hlavní případy použití skupin uživatelů při zřizování jsou:

Přiřazení lic encí: Přiřaďte licence skupinám, abyste členům skupiny automaticky poskytovali služby, jako jsou volání, schůzky, zasílání zpráv nebo hybridní služby.

Šablony nastavení: Použijte kolekce nastavení služeb (např. zasílání zpráv, schůzky, volání) na skupiny pro konzistentní uživatelský komfort.

Hromadná správa uživatelů: Hromadné přidávání nebo odebrání uživatelů prostřednictvím souborů CSV nebo synchronizace adresářů.

Automatizace a integrace: Použijte API nebo synchronizaci adresářů pro automatizovanou správu životního cyklu uživatelů a skupin.

Následující tabulka shrnuje různé možnosti správy skupin uživatelů a správy skupin v aplikaci.
Tabulka 7. Možnosti správy skupin a členství ve skupině
Varianta Popis Klady Nevýhody

přidělování skupin (skupiny) Vytvářejte a spravujte skupiny přímo v. Přidávání/odebrání členů ručně nebo prostřednictvím CSV. Plná kontrola nad členstvím ve skupině
Okamžitá aplikace licencí a šablon
Snadné vytváření a úpravy skupin Vyžaduje se ruční aktualizace
Riziko chyb při ručním nahrávání CSV
Žádná automatická synchronizace s externími adresáři

Synchronizované skupiny z Entra ID (Azure AD) nebo Active Directory Automaticky synchronizujte skupiny zabezpečení a členství z externích adresářových služeb. Automatizovaná synchronizace snižuje manuální práci
Zajišťuje konzistenci s podnikovým adresářem
Podporuje velké organizace
Nelze upravit členství ve skupině
Zpoždění synchronizace až 12 hodin
Vnořené skupiny vyžadují ruční výběr

Skupiny a SCIM 2.0 API (Skupiny) Použijte skupiny nebo rozhraní SCIM 2.0 API pro programovou správu skupin a členství Automatizace a integrace s jinými systémy
Škálovatelné pro velká nebo složitá prostředí
Vyžaduje vývojové úsilí
Složitost závisí na použití API

Zatímco synchronizované skupiny zajišťují konzistenci a nabízejí jediný bod správy, je možný hybridní přístup kombinující synchronizované skupiny a skupiny (buď spravované v řídicím centru nebo prostřednictvím rozhraní API). Například skupiny pro přiřazení licencí mohou být synchronizované skupiny a samostatná sada skupin může být použita pro přiřazení uživatelských a volajících šablon.

Tento komplexní přístup ke správě skupin uživatelů umožňuje organizacím efektivně spravovat uživatelské licence, nastavení, a zásady, což zajišťuje konzistentní a škálovatelné prostředí spolupráce.

Doporučený přístup při migraci z do

Primárním zdrojem dat pro uživatele je databáze, která obsahuje informace o koncovém uživateli. nicméně, obvykle není autoritativním zdrojem pro správu identit uživatele a co je důležitější, bude na konci přechodu vypnut, a proto je vyloučen jako dlouhodobý autoritativní zdroj informací o identitě.

Společnost Cisco doporučuje používat centralizovaný cloudový adresář, jako je Microsoft Entra ID (Azure AD), jako jediný zdroj pravdy pro identity uživatelů. Synchronizace uživatelů z Entra ID zajišťuje konzistenci, zjednodušuje správu a podporuje funkce jednotného přihlašování (SSO).

Aby bylo zajištěno, že všichni uživatelé jsou také přítomni v Entra ID, organizace by měly ověřit, zda uživatelské účty odpovídají účtům v Entra ID. To lze provést exportem seznamů uživatelů a jejich porovnáním se seznamy uživatelů Entra ID.

Stručně řečeno, doporučenou metodou zřizování je synchronizace uživatelů z Microsoft Entra ID (Azure AD) do Webex pomocí Průvodce Azure AD nebo aplikací SCIM. Ruční a hromadné zřizování souborů CSV jsou k dispozici jako doplňkové metody, ale pro velké organizace jsou méně škálovatelné a náchylnější k chybám. Zajištění, že Entra ID je autoritativním zdrojem a že všichni uživatelé existují v Entra ID, je zásadní pro úspěšnou migraci a konzistentní uživatelské prostředí napříč prostředími.

Přechod z místní adresářové služby, napříkladActive Directory, na cloudovou adresářovou službu, jako je Entra ID (Azure ID), je nezávislý na přechodu volání. Společnost Cisco doporučuje dokončit přechod na cloudovou adresářovou službu před zahájením přechodu volání.

Navrhování skupin uživatelů

Po přechodu podnikového adresáře z místního do cloudu sbírejte požadované skupiny uživatelů založené na požadavcích na licenci a šablonu funkcí. Pro každý skupinový dokument:

Název skupiny: jedinečný název skupiny.

Licence: licence, které mají být přiřazeny této skupině (pokud existují) a rozsah (měly by být licence přiřazeny stávajícím uživatelům nebo pouze novým uživatelům)

Šablony nastavení: Šablony volání aplikace Webex a uživatele.

Synchronizace adresářů: Bude tato skupina synchronizována z podnikového adresáře nebo se jedná o místní skupinu Webex zřízenou v Control Hub nebo prostřednictvím rozhraní API.

Popis: jak bude tato skupina používána a kteří uživatelé by měli být členy této skupiny

Tyto podrobnosti budou použity později během fáze implementace k vytvoření místních skupin nebo skupin v podnikovém adresáři a ke správě členství ve skupinách uživatelů.

Jednotné přihlášení (SSO)

Společnost Cisco doporučuje používat SSO pro ověřování uživatelů. Používání SSO má některé přesvědčivé výhody, včetně:

Zjednodušené ověřování uživatelů: Uživatelé se mohou jednou přihlásit pomocí svých firemních pověření (např. z Azure ID) a získat přístup k dalším integrovaným aplikacím, čímž eliminují potřebu více hesel a omezují výzvy k přihlášení. Tím se zvyšuje zabezpečení tím, že firemní hesla nebudou po ověření nikdy ukládána ani přenášena.

Zjednodušená správa uživatelů: Automatizuje vytváření uživatelských účtů, aktualizace a deaktivaci na základě změn v podnikovém adresáři, snižuje administrativní režii a zajišťuje přístup pouze oprávnění uživatelé.

Vylepšené zabezpečení: SSO snižuje únavu hesla a riziko narušení hesla centralizací ověřování prostřednictvím důvěryhodných poskytovatelů identit (IDP).

Snadná integrace vícefaktorové autentizace (MFA): MFA lze snadno podporovat buď prostřednictvím řešení Identity Access Management, jako je Cisco Duo, nebo prostřednictvím podpory M FA IdP.

Existuje několik možností implementace SSO pro služby:

SSO založené na SAML 2.0: Primární protokol podporovaný pro integraci SSO, který umožňuje bezpečnou výměnu ověřovacích informací mezi Id P a poskytovatelem služeb.

OpenID connect (OIDC): Podporováno jako alternativní moderní autentizační protokol pro integraci SSO.

Identita Webex: Pod porována také jako možnost poskytovatele identity.

SSO je konfigurováno a spravováno centrálně prostřednictvím, což vyžaduje výměnu metadat mezi vybraným IdP a vybraným IdP.

Po konfiguraci lze SSO před aktivací otestovat, aby bylo zajištěno správné nastavení.

Společnost Cisco podporuje integraci s několika testovanými a běžně používanými IDP a systémy správy identit (IAM), mimo jiné včetně:

Cisco Duo

Okta

Microsoft Active DirectoryFederační služby (ADFS)

Microsoft Azure

Ping Federate

OpenAM

F5 BIG-IP.

Tyto IDP odpovídají standardům SAML 2.0 nebo OpenID Connect a byly ověřeny z hlediska kompati bility s řešeními pro spolupráci Cisco.

Podpora více IdP

umožňuje organizacím konfigurovat SSO s více IDP tak, aby vyhovovaly složitým IT prostředím, jako jsou fúze, akvizice nebo decentralizovaná IT oddělení, kde různé skupiny používají různé IDP. Podpora více IdP může být implementována buď pomocí funkce Multiple IdP v nebo prostřednictvím integrace podnikového systému IAM, jako je Cisco Duo.

Podpora více poskytovatelů identit (IdP) řeší několik klíčových případů použití, kdy organizace vyžadují flexibilní a bezpečné ověřování napříč různými IT prostředími:

1. Fúze a akvizice

Když se společnosti spojují nebo získávají jiné, často mají oddělené IT infrastruktury a odlišné IDP, kteří se nemohou federovat. Podpora více IdP umožňuje uživatelům z obou organizací bezpečně ově řovat a spolupracovat, aniž by museli okamžitě sjednotit své systémy identity.

2. Více nezávislých IT oddělení

Velké organizace nebo vládní instituce mohou mít několik nezávislých IT oddělení, z nichž každý spravuje svůj vlastní IdP. Funkce více IdP umožňuje těmto oddělením udržovat vlastní autentizační systémy a zároveň uživatelům umožňuje bezproblémový přístup.

3. Různé skupiny uživatelů nebo domény

Organizace s různými skupinami uživatelů (např. zaměstnanci vs. dodavatelé) nebo s více e-mailovými doménami mohou nakonfigurovat pravidla směrování tak, aby požadavky na ověřování směrovaly na příslušného IdP na základě členství v doméně nebo skupině. To podporuje zásady diferencovaného přístupu a kontroly zabezpečení.

4. Podpora různých autentizačních protokolů

podporuje IDP SAML a OpenID Connect (OIDC), což organizacím umožňuje integrovat různé typy poskytovatelů identit podle jejich stávající infrastruktury a bezpečnostních požadavků.

5. Vylepšené zabezpečení a dodržování předpisů

Aktivací více IDP mohou organizace implementovat silnější ověřovací mechanismy, včetně vícefaktorového ověřování (MFA) prostřednictvím integrací, jako je Duo, a prosazovat konzistentní zásady zabezpečení napříč různými uživatelskými základnami.

6. Zjednodušené uživatelské prostředí

Uživatelé se mohou ověřovat pomocí svých stávajících přihlašovacích údajů od příslušných IDP, což poskytuje jednot né přihlašovací prostředí navzdory základní složitosti více systémů identity.

I když podpora více IdP poskytuje flexibilitu, vyžaduje pečlivou koordinaci mezi týmy zabezpečení a identity, aby byla zachována konzistentní bezpečnostní politika a zabránilo se potenciálním zranitelnostem.

Duo MFA s SSO pro

Duo Access Gateway (DAG) může ověřovat uživatele pomocí stávajících místních nebo cloudových adresářů, jako jsou Active Directory (AD) a OpenLDAP. Podporuje také integraci s dalšími poskytovateli identit, jako jsou Microsoft ADFS, Microsoft Azure, Okta, OneLogin, CAS a Shibboleth. Tato flexibilita umožňuje organizacím používat jejich aktuální adresářovou infrastrukturu pro Webex SSO s Duo MFA.

Duo funguje jako silná ověřovací vrstva nad autentizací primárního adresáře. Fungu je jako poskytovatel identity (IdP) pomocí SAML 2.0 k vynucení dvoufaktorového ověřování (2FA) před udělením přístupu k. Duo vyhodnocuje kontext uživatele, zařízení a sítě na základě konfigurovatelných zásad umožňujících nebo odepř ení přístupu, čímž zvyšuje zabezpečení nad rámec pouhého uživatelského jména a hesla. Duo také poskytuje flexibilní ovládací prvky zásad, například vyžadování MFA při každém přihlášení pro některé aplikace a méně často pro jiné.

Mezi výhody Cisco Duo patří:

Vylepšené zabezpečení: Přidává MFA odolnou proti phishingu, která chrání přístup a snižuje riziko ohrožených hesel.

Flexibilní zásady: Umožňuje podrobnou kontrolu nad požadavky na ověřování podle aplikace nebo skupiny uživatelů.

Integrace s existujícími adresáři: Podporuje místní služby AD, OpenLDAP, cloudové adresáře a různé poskytovatele SSO, čímž minimalizuje změny infrastruktury.

Uživatelské pohodlí: Podporuje jednotné přihlašování (SSO) ke snížení únavy heslem tím, že umožňuje uživatelům přihlásit se jednou a bezpečně přistupovat k více zdrojům.

Důvěryhodné koncové body: Podporuje důvěru zařízení pro klienty v systémech Windows a macOS, čímž zlepšuje stav zabezpečení.

Samoobslužná registrace: Inline registrace a dvojitá výzva zlepšují uživatelský komfort během nastavení MFA.

Duo MFA s SSO pro využívá k ověřování uživatelů existující adresáře, jako Active Directory je OpenLDAP nebo poskytovatele cloudových identit. Úlohou společnosti Duo je poskytovat silný druhý faktor autentizace založený na zásadách integrovaný prostřednictvím SAML 2.0, který zvyšuje bezpečnost při zachování uživatelského pohodlí prostřednictvím SSO. Mezi výhody patří lepší pozice zabezpečení, flexibilní pro sazování zásad, bezproblémová integrace a lepší uživatelský komfort.

Společnost Cisco doporučuje implementaci SSO pro uživatele. Pro lepší zabezpečení se doporučuje integrace s Cisco Duo.

Strategie Enterprise IAM a SSO by měla být nasazena před zahájením přechodu z na.

Vlastnosti

má plný doplněk základních funkcí, které jsou součástí služby. To zahrnuje mnoho funkcí volání na podnikové úrovni, které jsou k dispozici již mnoho let. Možná nevidíte 100% paritu mezi funkcemi a funkcemi, ale jak vidíte na obrázku níže, klíčové funkce volání jsou k dispozici v.

Webex Callingfunkce podnikové úrovně

Kromě mnoha uživatelských funkcí má základní systémové funkce, které jsou součástí platformy. Patří mezi ně funkce, jako jsou automatická obsluha, fronty hovorů, park volání atd. Všechny dostupné základní funkce systému můžete vidět v části Služba → Volání → Funkce, jak je znázorněno na obrázku Webex Callingzákladní funkce.

Webex Callingzákladní funkce

Automatická obsluha

Automatická obsluha umožňuje nepřetržitou automatizaci zpracování příchozích hovorů, což umožňuje efektivní zpracování hovorů bez nutnosti, aby osoba přijala každý hovor.

Automatická obsluha odpovídá na příchozí hovory a poskytuje volajícímu nabídku možností, kam chce směrovat svůj hovor. Může to být osoba, hlasová schránka nebo volací služba (např. Fronta volání). Vol ající pomocí číselné klávesnice svého telefonu zadá číslo z nabídky automatického telefonního ho voru.

Automatická obsluha podporuje následující klíčové funkce:

Obchodní a mimopracovní plány

Rozvrh prázdnin

Volba nabídky vytáčení, která nasměruje zákazníky tam, kam potřebují jít

Přizpůsobte pozdravy

Volba vytočit podle názvu

Možnosti přesměrování hovorů

Analýzy a reporty Control Hub.

Další informace naleznete v tématu S práva automatických telefonních hovorů.

Zavolejte Park

Call park dává uživatelům možnost snadno pozastavit hovor, aby jiný uživatel mohl snadno načíst, když je k dispozici, aby jej přijal. Uvolňuje také uživatele, který odpověděl na původní hovor, aby uskutečňoval nebo přijímal další hovory, zatímco je hovor zaparkovaný.

K dispozici jsou dva typy call parků:

Call park direct - umožňuje každému uživateli zaparkovat hovor na pobočku jiného uživatele nebo na rozšíření call parku, jak je definováno správcem

Skupina volání parku - umožňuje definované skupině uživatelů automaticky zaparkovat hovory proti dostupným cílům parku definovaným pro skupinu. Těmito cíli mohou být rozšíření členů skupiny nebo rozšíření call parku.

V závislosti na konfiguraci a typu parkování mohou uživatelé načítat hovory vytočením *88+><extension of parked call>, stisknutím klávesy linky přidružené k rozšíření parku volání nebo pomocí softwarové klávesy na svém IP telefonu.

Možnost odvolání je k dispozici pro vyvolání zaparkovaného hovoru po určité době uživateli, který hovor zaparkoval, nebo alternativnímu uživateli.

Další informace naleznete v tématu S práva parkování hovorů v Řídicím centru.

Vyzvednutí hovorů

Vyzvednutí hovorů umožňuje správci definovat skupinu uživatelů (členů), kteří mohou přijmout hovor na telefon jiného člena. To dává uživateli možnost přijímat hovory, když jsou jeho spoluhráči zaneprázdněni a nemohou přijmout příchozí hovor.

Uživatelé ve skupině musí být na stejném místě.

Uživatelé mohou k vyzvednutí hovoru použít buď stolní telefon, nebo svůj stolní telefon.

:

Podporuje vizuální a zvuková oznámení

Oznámení o příchozím hovoru

Vyzvednutí hovoru na základě faktu (vytáčení *98) nebo oznámení

Oznámení o vyzvednutí hovorů pro víceřádkové.

Stolní telefony:

Oznámení o příchozím hovoru

Zvukové zvonkohry a vizuální upozornění přes LED sluchátko. 6821 podporuje pouze zvukové zvonkohry

Pokud je typ oznámení vybrán v seznamu není žádný

Oznámení o vyzvednutí hovorů pouze pro primární linky.

Další informace naleznete v tématu Konfigurace skupiny pro vyzvednutí hovorů.

Fronta hovorů

zahrnuje fronty volání pouze hlasové jako součást svých základních funkcí a každý uživatel s licencí Professional může být součástí fronty hovorů, agent nebo supervizor. Tato funkce umožňuje uživatelům efektivně komunikovat se zákazníky. Fronty hovorů podporují podmnožinu některých základních funkcí call centra, jako jsou hlasové fronty, zpětné volání, směrování dovedností nebo priorit, správa front agentů, analytika, vytváření zpráv atd.

Výzva společnosti Cisco pro integraci Microsoft Teams umožňuje agentům přístup k hovorům a funkcím fronty volání přímo z jejich klienta Microsoft Teams.

Volací fronty podporují následující klíčové funkce:

Pozdravy a zprávy (uvítání, pohodlí, šepot atd.)

Držte hudbu

Zpětné volání

Zásady směrování fronty (noční služba, svátky, přeposílání)

Přihlášení/odhlášení do fronty agenta

Správa stavu fronty agentů

nebo podpora stolního telefonu

Dozorčí agent volá monitorovat, koupí, čluní nebo převezme kontrolu prostřednictvím přístupových kódů funkcí (FACS)

(přístup správce) pro:

správa fronty

Analýza a vykazování agentů a front

Správa fronty, agentů a supervizorů.

Další informace naleznete v tématu Konfigurace fronty hovorů.

má doplňkovou funkci Customer Assist, která poskytuje další funkce fronty hovorů a poskytuje agentům a supervizorům lepší uživatelský zážitek v rámci. Porovnání funkcí Fronty volání a Customer Assist najdete v tématu Porovnání Webex Callingfunkcí fronty hovorů a zákaznické podpory.

Huntská skupina

Hunt Groups umožňují směrování příchozích hovorů konkrétní skupině uživatelů prostřednictvím předem stanoveného vzoru směrování hovorů. Tím je zajištěno, že hovory jsou přijímány správnou skupinou uživatelů nebo odeslány do hlasové schránky k následnému sledování.

Jeden velký rozdíl mezi skupinami lovu a frontami volání spočívá v tom, že hovory nejsou ve frontě ve skupinách lovu, takže pokud nejsou k dispozici žádní uživatelé ve skupině Hunt, kteří by mohli přijmout hovor, bude odpojen, odeslán do hlasové schránky nebo přesměrován na jiné číslo (uživatel nebo služba).

Další informace naleznete v tématu S práva vyhledávacích skupin v Ří dicím centru.

Provozní režimy

Funkce provozních režimů umožňuje podnikům efektivně směrovat hovory do různých destinací (uživatelé, hlasová schránka, volací služby, jako je fronta hovorů). Místo a kdy je hovor směrován, je založeno na roz vrhu denní doby a dne v týdnu a každý uživatel může být oprávněn spravovat tyto režimy (plány) za účelem řízení změn směrování hovorů.

Například hovory do fronty volání mohou být směrovány do jiné fronty hovorů s agenty v jiném časovém pásmu, aby přijímali hovory mimo pracovní dobu, během pracovní doby směrovány k místním agentům, a během prázdnin mohou být směrovány do hlasové schránky pro následné sledování poté, co se agenti vrátí do kanceláře.

Autorizovaný uživatel může přepínat mezi těmito různými scénáři (režimy) přesměrování hovorů, pokud potřebuje změnit, kam jsou příchozí hovory směrovány po určitou dobu. Tito uživatelé mohou spravovat režimy prostřednictvím svých telefonů 6800/7800/8800 MPP, telefonů 9800 nebo v uživatelském centru na Manage modes.

Další informace naleznete v části Smě rování hovorů na základě provozních režimů v části Webex Calling.

Skupina stránkování

Stránkovací skupiny umožňují uživatelům uskutečnit jednosměrný hovor a odeslat zvukovou zprávu skupině uživatelů. Každá skupina může obsahovat až 75 cílových uživatelů a/nebo pracovních prostorů, na které se dostanete vytočením předdefinovaného čísla nebo rozšíření.

Když uživatel zavolá stránkovací skupinu, provede se simultánní hovor na všechny přiřazené cíle ve skupině, v tomto okamžiku může volající vyslovit své zprávy a zavěsit, jakmile jsou dokončeny.

Další informace naleznete v tématu Konfigurace stránkovací skupiny v Řídicím centru.

nahrávky

podporuje nahrávání hovorů uskutečněných nebo přijatých uživatelem. To může být vyžadováno pro potřeby kvality, zajištění, bezpečnosti nebo školení. Ve výchozím nastavení jsou hovory zaznamenávány, ale pokud jsou vyžadovány další funkce nahrávání nebo požadavky na dodržování předpisů, lze použít i jiné poskytovatele nahrávání třetích stran.

Při použití jako záznamové platformy jsou všechny nahrané hovory spravovány uvnitř. Plní správci s rolí Compliance Officer mohou nahrávat a stahovat nahrávky. Bez role Compliance Officer může správce smazat pouze nahrávky.

Další informace o této funkci a seznam nahrávání třetích stran naleznete v tématu S práva nahrávání hovorů pro Webex Calling.

Dosah jednoho čísla

Dosah jednoho čísla umožňuje volání na telefonní číslo uživatele pro vyzvánění více zařízení. To může zahrnovat další stolní telefony i mobilní telefony. Z těchto zařízení lze také uskutečňovat hovory a uživatelé mohou mezi nimi tlačit a vytáhnout hovory.

Další informace o této funkci a o tom, jak ji správce konfiguruje, naleznete v tématu Konfigurace dosahu jednoho čísla (kancelář kdekoli).

Další informace o tom, jak může uživatel spravovat a konfigurovat tuto funkci pro sebe v Webex User Hub (portálu), naleznete v tématu Konfigurace dosahu jednoho čísla (kancelář kdekoli).

Skupina hlasové schránky

Skupiny hlasové schránky umožňují sdílenou hlasovou schránku, kterou lze přiřadit uživateli nebo funkci směrování hovorů. Některé z důvodů, proč může být vyžadována skupina hlasové schránky, jsou:

Obecná hlasová schránka pro oddělení nebo pracovní skupinu

Přidání možnosti hlasové schránky do automatické obsluhy nebo skupiny lovu

Odesílání přepadových hovorů z fronty hovorů

Uživatelé, kteří potřebují pouze hlasovou schránku.

Další informace naleznete v tématu Správa sdílené hlasové schránky a příchozí faxové schránky pro. Webex Calling

Konzola obsluhy je uvedena na stránce Funkce volání ve Webexu, jedná se však o doplňkovou funkci, která vyžaduje zakoupení licence na konzoli doprovodu k použití.

Další informace naleznete v tématu Začínáme s konzolou Attendant Console.

Informace o všech funkcích, včetně některých doplňkových funkcí, najdete v tématu Funkce dostupné podle typu licence pro Webex Calling.

Tabulka 1. Informace, které je třeba zachytit pro každé místo
Informace	Komentář
Rozsah (y) rozšíření	Každé umístění může mít rozšíření začínající různými číslicemi. Jedna číslice musí být ušetřena pro číslici řízení mezi místy (například 8) a jedna pro číslici řízení PSTN (například 9). Žádný rozsah rozšíření nemůže začínat žádnou z těchto dvou číslic. Všechny rozsahy rozšíření všech umístění musí mít stejnou délku.
Rozsah (y) DID	-
Číslice řízení PSTN	-
Kód webu	Všechny kódy stránek všech míst musí být jedinečné a mít stejnou délku.
Hlavní číslo	Při vytváření umístění je třeba zřídit dva DID. Jedno jako hlavní číslo (například přiřazené službě automatické obsluhy) a jedno pro portál hlasové sch ránky. Zajistěte jeden DID pro číslo hlasové schránky.
Číslo hlasové schránky
Počet licencí	Požadované licence podle typu včetně Standard, Professional, Workspace, Route List, Outbound Calling Plan.
Souběžné hovory v rušné době	Součet souběžných hovorů mezi zařízeními a mezi zařízeními a místní bránou (PSTN a volání do zařízení). Potřebné k určení požadované šířky pásma přístupu k internetu.
Země	-
Časové pásmo	-
Jazyk	-
Kontakt (jméno, telefon, e-mail)	-
Adresa (ulice, město, stát, PSČ)	-
Fyzické odeslané umístění záchranných služeb pro koncové body	Místo odeslání zařízení používané pro tísňové volání obecně zahrnuje následující: adresa budovy, adresa budovy+číslo patra, adresa budovy+číslo apartmá nebo adresa budovy + číslo podlaží + číslo kanceláře/kubické číslo.
Jedinečné fyzické umístění v síti na zařízení pro tísňové služby	Fyzické umístění sítě pro tísňové volání obecně zahrnuje následující: přepínač/switchport pro kabelová zařízení, identifikátory základní sady služeb (AP) bezdrátového přístupového bodu (BSSID) pro bezdrátově připojená zařízení a/nebo místní podsítě IP pro koncová zařízení.

Tabulka 2. Příklad podnikového číslování
Stránky	Rozšiřující rozsah	Kód webu	Řada Enterprise
NYC	2XXX	202	8 202 2XXX
SFO	3XXX	203	8 203 3XXX
RTP	2XXX	204	8 204 2XXX

Tabulka 3. Rozsahy prodloužení pevných délek
Stránky	Rozšiřující rozsah	Rozšíření	Kód webu	Řada Enterprise
NYC	2XXX	2XXX	202	8 202 2XXX
SFO	8XXX	7XXX	203	8 203 7XXX
RTP	1XX	11XX	204	8 204 11XX

Tabulka 4. Přechod sedmimístné volby

Stránky	Rozšíření	Kód webu	Řada Enterprise	Stránka óda	Enterprise Angle
NYC	2XXX	22	8 22 2XXX	822	8 822 2XXX
SFO	8XXX	23	8 23 7XXX	823	8 823 7XXX
RTP	1XXX	24	8 24 11XX	824	8 824 11XX

Tabulka 5. Možnosti zřizování uživatelů - souhrn
Metoda přiřazení	Klady	Nevýhody
Manuální přes	Jednoduché pro několik uživatelů. Umožňuje přesnou a podrobnou kontrolu nad přiřaz ením licencí.	Není škálovatelný, časově náročný Při ručním zadávání je náchylný k lidské chy bě.
Automatické šablony licencí	Škálovatelný Snižuje manuální chyby Lze použít pro nové i stávající uživatele.	Vyžaduje platná telefonní čísla a místa. Složitější nastavení Vyžaduje také skupiny uživatelů na skupinu uživatelů s ekvivalentními licenčními požadavky.
Hromadné nahrávání CSV	Efektivní pro velké uživatelské sady Umožňuje současné přiřazování licencí, telefonních čísel a rozšíření.	Vyžaduje pečlivé formátování CSV Potenciál chyb, pokud telefonní čísla nebo přípony chybí nebo jsou nesprávné.
Přiřazení na základě rozhraní API	Automatizovatelný, flexibilní. Umožňuje současné přiřazování licencí, telefonních čísel a rozšíření.	Vyžaduje vývoj a znalosti API.

Tabulka 6. Možnosti zřizování uživatelů pro
Způsob poskytování	Popis	Klady	Nevýhody
Manuál	Vytvářet/spravujte uživatele jednotlivě v	Jednoduché pro několik uživatelů; není potřeba žádná infrastruktura	Není škálovatelný; časově náročné pro mnoho uživatelů
Hromadné (soubor CSV)	Importujte/aktualizujte uživatele hromadně prostřednictvím CSV	Efektivní pro skupiny; není nutné kódování	Manuální příprava CSV; méně dynamické
Lidé a SCIM 2.0 API	Programová správa uživatelů prostřednictvím rozhraní API Webex	Flexibilní; podporuje automatizaci a integraci	Vyžaduje rozvoj a infrastrukturu
Synchronizace adresářů	Automatická synchronizace z aplikací AD, Entra ID, SCIM, Unified CM	Automatizuje životní cyklus; podporuje filtrování a mapování	Složitost nastavení: některé možnosti mají omezené funkce nebo vyžadují infrastrukturu

Tabulka 7. Možnosti správy skupin a členství ve skupině
Varianta	Popis	Klady	Nevýhody
přidělování skupin (skupiny)	Vytvářejte a spravujte skupiny přímo v. Přidávání/odebrání členů ručně nebo prostřednictvím CSV.	Plná kontrola nad členstvím ve skupině Okamžitá aplikace licencí a šablon Snadné vytváření a úpravy skupin	Vyžaduje se ruční aktualizace Riziko chyb při ručním nahrávání CSV Žádná automatická synchronizace s externími adresáři
Synchronizované skupiny z Entra ID (Azure AD) nebo Active Directory	Automaticky synchronizujte skupiny zabezpečení a členství z externích adresářových služeb.	Automatizovaná synchronizace snižuje manuální práci Zajišťuje konzistenci s podnikovým adresářem Podporuje velké organizace	Nelze upravit členství ve skupině Zpoždění synchronizace až 12 hodin Vnořené skupiny vyžadují ruční výběr
Skupiny a SCIM 2.0 API (Skupiny)	Použijte skupiny nebo rozhraní SCIM 2.0 API pro programovou správu skupin a členství	Automatizace a integrace s jinými systémy Škálovatelné pro velká nebo složitá prostředí	Vyžaduje vývojové úsilí Složitost závisí na použití API

Implementovat

Připravenost k síti

Počáteční nastavení

Ověření domény

Prohlášení (převod) existujících uživatelů

Konfigurace a testování synchronizace adresářů

Nastavení a testování jednotného přihlašování (SSO)

Pořízení, poskytování a ověřování licencí

Webex Callingnastavení služby

Pilotní migrace

Zakoupit PSTN

Konfigurace umístění

Integrace s místním řízením hovorů

Migrace uživatelů v dávkách

Pracovní prostory

Zajišťovací zařízení

Konfigurace funkcí

Přijímací zkoušky

Připravenost k síti

Prvním krokem při přechodu na je zajištění spolehlivého a bezpečného připojení k internetu mezi místní sítí a cloudem.

Vzhledem k tomu, že většina organizací se připojuje k internetu prostřednictvím jednoho nebo více firewall ů nebo bezpečnostních zařízení, je nezbytné ověřit, zda jsou podporovány požadované toky provozu.

Správci sítě a zabezpečení musí těmto tokům rozumět z hlediska:

Směr (příchozí vs. odchozí)

Protokoly (Příklad - SIP TLS, SRTP, HTTPS)

Roz@@ sahy IP adres používané službami

Čísla port ů, která musí být otevřena nebo povolena.

Tím je zajištěno, že firemní firewally, zařízení NAT a další síťová infrastruktura jsou správně nakonfigurovány tak, aby vyhovovaly provozu při zachování podnikových zásad zabezpečení.

Informace o požadovaných tocích včetně adresy IP, portů a protokolů naleznete v části Referenční informace o portu pro Webex Calling. Tyto informace slouží ke konfiguraci brány firewall, proxy serverů a další síťové infrastruktury ve stávajícím nasazení pro povolení síťových toků.

Decentralizovaný internetový únik z každé pobočky nebo webu je doporučeným přístupem pro služby cloudové spolupráce, jako je. Umožněním místního ukončení provozu tento model:

Snižuje zpáteční zpoždění a chvění a zlepšuje celkovou kvalitu hovoru

Efektivně se škáluje, protože více uživatelů a webů přechází na

Bezproblémově pracuje s SD-WAN, která dokáže dynamicky směrovat relace k nejbližšímu vstupnímu bodu cloudu pro optimální výkon

Umožňuje sledovat polohu uživatele na základě jejich veřejné IP adresy, což pomáhá s analýzou cesty médií a odstraňováním problémů.

Kromě toho musí organizace zajistit dostatečnou šířku pásma internetu na každém místě. Šíř ka pásma by měla být dimenzována na základě očekávaného počtu souběžných hovorů, vybraného kodeku (např. Opus nebo G.711) plus režijních nákladů na signalizaci, opětovné vysílání a růst. To je v souladu s přípravnou fází životního cyklu PPDIO a vytváří pevný základ pro migraci.

Počáteční nastavení

Pododdíl počátečního nastavení ve fázi implementace nasazení je základem pro vytvoření dobře strukturovaného a spravovatelného prostředí cloudových volání. Tato fáze zahrnuje kritické úkoly, jako je nastavení organizace, získávání a přiřazování licencí a ověření a nárokování domén vaší společnosti, aby byla zajištěna správná správa a zabezpečení uživatelů. Kromě toho zahrnuje zřizování licenčních šablon pro automatizaci přiřazování uživatelských licencí, konfiguraci jednotného přihlašování (SSO) pro zjednodušení ověřování uživatelů a zvýšení zabezpečení a úpravu nastavení služeb a klienta tak, aby odpovídaly organizačním zásadám a potřebám uživatelů. Dokončení těchto činností počátečního nastavení zajišťuje, že prostředí je správně nakonfigurováno pro škálovatelnost, zabezpečení a bezproblémové uživatelské prostředí, což připravuje půdu pro následné nasazení a provozní fáze.

Ověření domény

Aby bylo možné identifikovat uživatele registrované na e-mailových doménách vaší společnosti, je nezbytné ověřit vaše domény. Bez ověření domény budou uživatelé přiřazeni spotřebitelské organizaci, což komplikuje správu uživatelů pro vaši společnost. Ověření domény je povinný krok, který umožňuje vaší organizaci požadovat a efektivně spravovat tyto uživatele.

Ujistěte se, že jsou ověřeny všechny domény přidružené k e-mailovým adresám vašich uživatelů. Ově ření domény není exkluzivní; stejnou doménu lze ověřit ve více organizacích.

Další informace o správě domén naleznete v tématu Správa domén.

Prohlášení (převod) existujících uživatelů

Po úspěšném ověření domén můžete pokračovat v nárokování uživatelů, kteří se zaregistrovali k používání e-mailových domén vaší společnosti ve vaší organizaci. Tento proces konsoliduje všechny uživatele pod jeden organizační deštník, což umožňuje centralizovanou správu a zjednodušenou správu. Nárokováním těchto uživatelů zajistíte, že vaše společnost má plnou kontrolu nad uživatelskými účty, což vám umožní přiřadit příslušné licence, konfigurovat služby a efektivně poskytovat potřebnou podporu. Tento přístup jednot né správy zvyšuje zabezpečení, zjednodušuje zřizování uživatelů a zajišťuje konzistentní přístup ke službám v celé organizaci. Tvrzení uživatelů také brání jejich správě v externích nebo spotřebitelských organizacích, čímž zachovává organizační integritu a kontrolu nad zdroji spolupráce.

Další informace o nárokování uživatelů naleznete v tématu Prohlášení uživatelů vaší organizaci (převod) uživatelů.

Konfigurace a testování synchronizace adresářů

Chcete-li umožnit bezproblémovou správu uživatelů a skupin, můžete synchronizovat uživatele a skupiny z podnikového adresáře buď Microsoft Entra ID (dříve Azure AD) nebo Microsoft Active Directory (AD). Tento proces zajišťuje, že identity uživatelů a členství ve skupinách jsou konzistentně udržovány ve vašem prostředí.

Pro organizace, které implementují postupné nasazení, je zásadní kontrolovat a omezit rozsah synchronizace během počátečního zavádění. To minimalizuje riziko nezamýšlených změn a umožňuje cílené testování před širším přijetím.

Nejúčinnější metodou filtrování synchronizovaných uživatelů je využití členství ve skupině adresářů:

1
Vytvoření vyhrazené synchronizační skupiny: Ve svém podnik ovém adresáři (Microsoft Entra ID nebo AD) vytvořte skupinu zabezpečení speciálně pro synchronizaci (například synchronizační skupinu).

2
Naplnění skupiny cílovými uživateli: Do této skupiny přidejte pouze uživatele, které chcete synchronizovat (například testovací skupinu během pilotní fáze). To vám umožní pevně řídit, kdo je součástí procesu synchronizace.

3
Konfigurace synchronizační smlouvy s filtrováním založeným na skupinách: Při nastavování dohody o synchronizaci v zřizování Directory Connector nebo Entra ID nakonfigurujte rozsah tak, aby zahrnoval pouze uživatele, kteří jsou členy určené skupiny.

Pro Microsoft Entra ID můžete v nastavení zřizování použít přiřazení založená na skupinách

Pro službu AD můžete definovat filtr LDAP tak, aby zahrnoval pouze uživatele patřící do určené skupiny.

4
Rozbalte skupinu podle potřeby: Jak postupujete do širších fází nasazení, jednoduše přidejte do synchronizační skupiny další uživatele nebo skupiny. Rozsah synchronizace se automaticky rozšíří tak, aby zahrnoval tyto uživatele, což umožní řízené a postupné zavádění.

Příklad implementačních kroků:

V aktivním adresáři:

Vytvořte skupinu zabezpečení s názvem synchronizační skupina.

Přidejte požadované pilotní uživatele do této skupiny.

Nastavte Directory Connector pomocí filtru LDAP, například: (memberOF=CN=WebEx Sync Group, OU = Groups, DC=YourDomain, DC=COM).

Do Microsoftu zadejte ID:

Vytvoření skupiny s názvem synchronizační skupina

Přiřaďte skupinu k nastavení zřizování v Entra ID

Budou zřízeni pouze uživatelé v této skupině.

Před aplikací na celou organizaci vždy otestujte synchronizaci založenou na skupinách v neprodukčním prostředí

Pravidelně kontrolujte členství ve skupině, abyste zajistili synchronizaci pouze oprávněných uživatelů

Pro průběžnou správu automatizujte aktualizace členství ve skupině na základě obchodních pravidel nebo HR systémů, pokud je to možné.

Odkazy:

Synchronizace uživatelů Entra ID do Control Hub

Nastavení aplikace Entra ID Wizard v Control Hubu

Adresářový konektor

Nastavení a testování jednotného přihlašování (SSO)

Jednotné přihlašování (SSO) zvyšuje zabezpečení a zjednodušuje přístup uživatelů tím, že umožňuje uživatelům ověřit se jednou pomocí svých fire mních přihlašovacích údajů a získat bezproblémový přístup k nim. podporuje integraci SSO s IDP vyhovujícími SAML 2.0, včetně Microsoft Entra ID (dříve Azure AD), federovaných řešení Active Directory (AD) a různých IDP třetích stran.

V tomto okamžiku by mělo být implementováno a testováno navržené nastavení SSO.

Odkazy:

Integrace jednotného přihlášení do řídicího centra

nakonfigurovat jednotné přihlášení pro správu webex

Konfigurace jednotného přihlášení pomocí Microsoft Entra ID

SSO s více IDP

Správa jednotného přihlášení při integraci v Control Hub

Pořízení, poskytování a ověřování licencí

V rámci počátečního nastavení pro, je nezbytné pořídit, poskytnout, a ověřit příslušné licence pro efektivní umožnění a správu služeb. Proces nákupu zahrnuje výběr typů licencí na základě uživatelských rolí a úloh, jako jsou licence Professional, Standard a Workspace. Licence jsou generovány a poskytovány prostřednictvím softwarových platforem společnosti Cisco nebo prostřednictvím partnerů. Po zadávání zakázek a poskytování, je třeba ověřit správné počty licencí. Tento proces zajišťuje, že organizace má aktivované správné licence a připravené k použití při nasazení.

V rámci počátečního nastavení licencí v, je důležité nakonfigurovat automatické licencování založené na organizaci, aby se zjednodušilo přiřazování licencí novým uživatelům. Toto nastavení umožňuje automatické udělování licencí při přidávání uživatelů do organizace, což eliminuje potřebu ručního přiřazování licencí. Při konfiguraci automatického licencování na úrovni organizace vyberete služby, které chcete přiřadit, a definovat rozsah, například použití licencí pouze pro budoucí uživatele nebo zahrnutí stávajících uživatelů.

Pokud však plán nasazení zahrnuje použití automatického licencování na úrovni skupiny, můžete se rozhodnout nepřiřadit licence na úrovni organizace, abyste předešli konfliktům nebo duplicitnímu přiřaz ení licencí. Při automatickém licencování na úrovni skupiny jsou licence přiřazovány na základě členství ve skupině. Uživatelé ve více skupinách obdrží licence ze všech příslušných přiřazení skupin.

Konfigurace přiřazení licencí založená na skupině musí být provedena po dokončení synchronizace adresářů, aby existovaly synchronizované skupiny a mohly být použity pro přiřazení licencí.

Konkrétně automatické přiřazení licence vyžaduje další podrobnosti o zřizování, jako je umístění uživatele a přiřazení telefonního čísla. Pracovní telefonní číslo uživatele musí být ve formátu +E.164, předem zřízené a přiřazené platnému umístění, aby mohla být licence automaticky aktivována. Pokud tyto podmínky nejsou splněny, nebudou uživateli poskytovány služby automaticky a může vyžadovat ruční zásah.

Stručně řečeno, nakonfigurujte automatické licencování založené na organizaci pro nové uživatele, pokud chcete široké přiřazení licencí pro celou organizaci. Pokud dáváte přednost podrobnějšímu řízení nebo máte různé licenční potřeby pro každou skupinu, nakonfigurujte automatické licencování na úrovni skupiny a vyhněte se přiřazování licencí na úrovni organizace, abyste zabránili překrývání a zajistili řádnou správu licencí.

Webex Callingnastavení služby

Je nezbytné provést komplexní kontrolu a konfiguraci nastavení globálních služeb uvnitř.

Začněte přístupem do sekce nastavení a přechodem do části nastavení. Pečlivě prozkoumejte každou konfigurovatelnou možnost, mimo jiné včetně konfigurace interního vytáčení, parametrů tísňového volání, zá sad směrování hovorů, správy hlasové schránky a výchozího nastavení zařízení.

Upravte tato globální nastavení tak, aby odrážela zásady a rozhodnutí o návrhu vaší organizace.

Taky, nastavení nastavení a šablony uživatelů a aplikací.

Pilotní migrace

Během fáze implementace, provedení pilotní migrace představuje kritický milník při ověřování přechodu z na. Tento pilotní projekt zahrnuje zřízení reprezentativní podskupiny uživatelů v jednom nebo více lokalitách na platformě, což zajišťuje, že vybraná populace odráží různé případy použití a organizační role. Souběžně s migrací uživatelů musí být základní služby spolupráce včetně hlasové schránky, automatických telefonních hovorů, front volání a vyhledávací skupiny převedeny na jejich ekvivalenty, aby byla zacho vána kontinuita provozu a funkčnost služeb.

Pilotní migrace by měla využívat stejnou kombinaci nástrojů poskytovaných společností Cisco a nástrojů pro migraci třetích stran, které jsou plánovány pro širší organizační nasazení, a zajistit, aby procesy, pracovní postupy automatizace a integrační body byly důkladně ověřeny za reprezentativních podmínek.

Primární cíle tohoto pilotního nasazení jsou dvojí: za prvé, ověřit a zdokonalit procesy přechodu typu end-to-end, včetně pracovních postupů zřizování uživatelů, postupů migrace dat a konfigurace koncových bodů; a za druhé, komplexní ověření funkčnosti migrovaných služeb za provozních podmínek reálného světa.

Tento postupný přístup umožňuje projektovému týmu identifikovat a napravit jakékoli technické nebo procedurální problémy v kontrolovaném prostředí, shromažďovat zpětnou vazbu uživatelů o nové platformě, posoudit účinnost vybraných migra čních nástrojů a získat důvěru v metodiku migrace před pokračováním v širším organizačním nasazení.

Zjištění získané během této pilotní fáze jsou nápomocné při optimalizaci následných migračních vln a zajištění plynulého přecho du s minimalizací rizik pro celý podnik.

Zakoupit PSTN

Chcete-li získat služby PSTN pro, nejprve vyberte možnost připojení PSTN v.

Pokud organizace plánuje dočasně nebo neomez eně udržovat hybridní řízení duálních hovorů (fáze 1 na obrázku Fázovaný přechod volání: hybridní a clou dové), bude muset nasadit jednu nebo více místních bran pro místní PSTN, aby bylo možné volání mezi koncovými body a koncovými body nasadit jednu nebo více místních bran .

Pokud je konečným cílem úplný přechod (fáze 2) do cloudu včetně PSTN, bude pro PSTN vyžadován buď plán volání Cisco nebo možnost Cloud Connect for.

Spolupracujte s vybraným poskytovatelem na objednání a portu telefonních čísel před jejich konfigurací. Objednávání telefonních čísel nebo iniciování objednávek portů je vyžadováno/možné pouze pro místní PSTN a Cloud Connect pro. U tarifů volání společnosti Cisco je objednávání a portování zahájeno z Control Hub, jakmile je místo vytvořeno, a v zemích, kde je k dispozici plán volání Cisco. Další informace o plánech Cisco Calling najdete v tématu Začí náme s plány Cisco.

V rámci implementace PSTN se ujistěte, že váš poskytovatel povolil příchozí i odchozí služby PSTN pro vaši polohu. Kromě toho proveďte testovací hovory a ověřte, zda jsou hovory směrovány správně přes zvolené připojení PSTN.

Konfigurace umístění

Před přidáním uživatelů a zařízení je nutné zřídit místa volání. Pro každé místo musí být zadána platná adresa ulice. V USA a Kanadě je tato adresa ověřena a používána platformou k odesílání informací o poloze PIDF-LO pro tísňová volání.

Při konfiguraci umístění, která používají místní síť PSTN, je třeba odpovídajícím způsobem nastavit místní brány. V aplikaci musí být vytvořen kmen a skupina tras pro každou místní bránu a skupina tras je poté přiřazena jako volba PSTN pro umístění. Společnost Cisco důrazně doporučuje vždy zvolit skupinu tras jako volbu PSTN, protože tento přístup umožňuje v budoucnu snadno přidat další kmeny, což podporuje škálovatelnost i redundanci. Společnost Cisco také doporučuje povolit podporu duální identity a P-Charge-Info na každém kmeni PSTN, protože to zjednodušuje identifikaci fakturovatelné strany pro odchozí přímé nebo přesměrované hovory. Pokud váš poskytovatel služby PSTN používá pro fakturaci jinou hlavičku, můžete zkopírovat informace z hlavičky P-Charge-Info na místní bráně do požadované hlavičky fakturace.

Pro místa, která používají Cloud Connect pro nebo Cisco Calling Plan jako možnost PSTN, jednoduše vyberte příslušnou volbu PSTN pro umístění během nastavení. Pokud umístění používá buď Cloud Connect pro nebo místní PSTN, budete muset přidat telefonní čísla, která byla objednána v předchozím kroku. Čísla lze přidat jako neaktivní, pokud nechcete, aby byla okamžitě zahrnuta do směrování hovorů; tato čísla můžete aktivovat později, když jsou přiřazena uživatelům nebo funkcím.

Je důležité vždy nastavit hlavní číslo pro každé místo. Hlavní číslo lze přiřadit uživateli nebo funkci, například automatickému obsluze. Chcete-li povolit hlasovou schránku v daném místě, nezapomeňte nastavit číslo pilota hlas ové schránky, známé také jako číslo hlasového portálu.

Mezi další nastavení pro místa volání patří konfigurace podrobností tísň ového volání, jako je číslo zpětného volání tísňového volání, možnosti oznámení a vylepšené funkce tísňového volání. Měli byste také zkontrolovat a upravit nastavení nahrávání, jazykové předvolby a konfigurace zařízení podle potřeby pro každé umístění. Pokud vaše organizace používá zkrácenou interní internetovou volbu s podnikovými významnými čísly, nezapomeňte nakonfigurovat jedinečný kód lokality pro danou lokalitu v nastavení interního vytáčení . A konečně, pokud externí vytáčení vyžaduje číslici odchozího vytáčení, nezapomeňte ji nastavit v nastavení externího vyt áčení. Pokud je nakonfigurována číslice odchozího vytáčení, společnost Cisco doporučuje povolit vynucování odchozích číslic vytáčení, aby byla zajištěna konzistence.

Integrace s místním řízením hovorů

Pro integraci s místním řízením hovorů je nutné nakonfigurovat kmeny, skupiny tras, podnikové vytáčecí plány a umístění i globální nastavení. Začněte nastavením kmenů a místních bran určených pro propojení s místním systémem řízení hovorů; tento krok je vyžadován pouze v případě, že jsou nutné vyhrazené kmeny. Pokud jsou stávající kmeny a skupiny tras dostatečné pro vaše nasazení, lze je znovu použít pro místní propojení bez další konfigurace.

Jakmile jsou vytvořeny kmeny a skupiny tras, pokračujte v vytváření podnikových vytáčecích plánů a přiřaďte příslušnou skupinu tras jako cíl pro každý vytáčecí plán. Pokud integrace zahrnuje více místních systémů řízení hovorů připojených prostřednictvím různých kmenů, bude vyžad ováno více telefonních plánů. Je důležité zajistit, aby tyto vytáčecí plány obsahovaly pouze vzory nezbytné pro směrování ho vorů do místních cílů.

Pokud vaše nasazení vyžaduje podporu pro neznámé směrování rozšíření, měla by být tato funkce povolena na úrovni umístění. Pokud je navíc aktivováno směrování neznámého rozšíření, musíte zadat maximální délku neznámého rozšíření v části Smě rování hovorů mezi místy a místy nastavení volacích služeb v. Tím je zajištěno bezproblémové směrování hovorů a správné zpracování scénářů vytáčení na základě rozšíření ve vašem integrovaném prostředí.

Migrace uživatelů v dávkách

Když migrujete uživatele z na, možná nebudete moci přesunout všechny uživatele současně. To může být způsobeno několika důvody, mimo jiné včetně počtu webů nebo uživatelů, doby trvání přechodu na web a/nebo skupinu uživatelů najednou, omezeného IT nebo webového zdroje pro podporu okna změny, trvání okna změny, složitosti změny atd.

Při migraci uživatelů ve fázích je důležité určit, kteří uživatelé musí migrovat společně ve stejné dáv ce. Primárním cílem je společně migrovat uživatele, kteří mají vzájemnou závislost na svých volacích službách a funkcích. Chcete zajistit, aby všechny jejich funkce volání (Příklad - Fronty volání) byly plně funkční stejně jako před zapnutím přechodu.

I když implementujete propojení volání mezi místními bránami a s nimi, nelze sdílet sdílené služby nebo funkce napříč tímto připojením. Proto je třeba identifikovat závislosti mezi uživateli tím, že se podíváte na funkce, jako jsou:

Monitorování ostatních uživatelů pomocí BLF

Ve stejném loveckém pilotu, frontě volání atd

Sdílené řádky

Použití vyzvednutí hovorů

Používání stejných čísel parkovacích míst

Interkom

Vedoucí pracovník/administrátor.

Příkladem může být uživatel, který je součástí skupiny Hunt, na kterou se přechází. Tento uživatel přejde do skupiny Hunt Group a se všemi ostatními členy skupiny Hunt Group. Proto, po přechodu mohou Hunt Group a její členové úspěšně odpovídat na hovory na nové platformě.

To se stává náročnějším, když jsou uživatelé připojeni k různým skupinám uživatelů pro různé služby a funkce volání. To bude vyžadovat přechod více než jedné skupiny uživatelů a jedné volací služby současně.

Pomocí výstupu z nástroje Migration Insights nebo nástroje třetí strany, který jste použili ve fázi přípravy, určete, kteří uživatelé a funkce mají být seskupeny dohromady. Tento výstup by měl být použit k vytvoření plánu migrace a poskytne vám přehled o tom, jak seskupíte uživatele a funkce, které potřebují provést přechod společně.

Klíčové kroky při přechodu dávky uživatelů jsou:

Identifikace uživatelů pro společnou migraci

Ověřte, zda jsou všichni uživatelé v

Ověřte, že všechny TN pro uživatele existují

Ověřte správný formát telefonního čísla v adresáři

Zkontrolujte, zda jsou šablony licencí a nastavení pro skupiny uživatelů správně nastaveny

Ověření nebo konfigurace všech volacích služeb a funkcí pro skupinu uživatelů (před nebo během přechodu podle potřeby)

Ve firemním adresáři přidejte uživatele do skupiny uživatelů povolených volání

Využití nástrojů - nástroje pro migraci uživatelů a funkcí a/nebo nástroje třetích stran

Po přechodu zakázat/odstranit číslo adresáře uživatele/zařízení a volat funkce/služby.

Po migraci skupiny uživatelů otestujte podmnožinu uživatelů, abyste ověřili, že všechny jejich funkce a služby pro volání fungují správně. Pokud jsou funkce volání, jako je fronta volání, skupiny hledání atd., přecházeny se skupinou uživatelů, otestujte tyto volací služby, zda jsou správné funkce.

Pracovní prostory

V aplikaci se pracovní prostor týká sdíleného umístění (jako je konferenční místnost, místnost pro schůze nebo pracovní stůl), kterému lze přiřadit zařízení, rozšíření a uživatelé. Na rozdíl od tradičních telefonů Unifed CM jsou pracovní prostory:

Zaměřeno na polohu: vázáno na fyzické prostory.

Flexibilní pro zařízení: může mít jedno nebo více zařízení (stolní telefony, desky atd.).

Jakmile jsou pracovní prostory identifikovány jako součást přechodu na, lze je přidat do části Zařízení. Každý pracovní prostor potřebuje přiřazení zařízení, a pokud je již v němUnified CM, je třeba je resetovat nebo znovu zřídit. funkce, jako je hlasová schránka, přesměrování hovorů a vyzvednutí hovorů, lze povolit nebo zakázat a zásady lze podle potřeby použít pro videohovory, parkování hovorů a mobilitu. Otestu jte každý pracovní prostor interními a externími hovory, testováním funkcí videa, konferencí a mobility . Nakonec dejte uživatelům vědět o všech použitelných procesech pro zařízení pracovního prostoru a rezervace.

Další informace o pracovních prostorách v aplikaci naleznete v části Pracovní prostory.

Zajišťovací zařízení

Telefony, na které jsou aktuálně registrovány, budou muset být migrovány jako součást přechodu do cloudu. Aby byla migrace co nejjednodušší s minimální pravděpodobností selhání, doporučuje společnost Cisco migrovat fyzické weby nebo oddělení současně. Může však být vyžadováno migrace uživatelů v dávkách kvůli závislostem funkcí. Další podrobnosti naleznete v části Migrace uživatelů v dávkách.

Všechny podporované telefony, ze kterých potřebujete přejít, budou muset být nakonfigurovány jako uživatel nebo pracovní prostor a fyzický telefon bude muset být znovu nakonfigurován, aby se mohl zaregistrovat . Kromě toho telefony řady 7800 a 8800 potřebují upgrade firmwaru z firmwaru Enterprise na firmware Multiplatform Phone (MPP). Tento proces zahrnuje načtení přechodného firmwaru před načtením firmwaru MPP požadovaného pro registraci. Vyžaduje také příslušnou migrační licenci. Společnost Cisco tento proces v posledních několika letech vylepšila, aby vám usnadnila upgrade vašich telefonů s firmwarem Enterprise na firmware MPP. Další informace o krocích k dokončení upgradu firmwaru naleznete v tématu Převod IP telefonů Cisco řady 7800 a 8800 mezi firmwarem Enterprise a firmwarem MP P.

Kromě kroků uvedených v tomto článku obsahuje vestavěný nástroj Migrace telefonu doWebex Calling, který můžete použít k migr aci telefonů 7800 a 8800 z firmwaru Enterprise na MPP. Tento nástroj také umožňuje přidávat telefony a přiřadit je příslušným uživatelům nebo pracovním prostorům. Další informace o používání nástroje naleznete v tématu Migrace telefonu.

Pro všechny telefony řady 9800 registrované s výše uvedeným požadavkem na migraci firmwaru neplatí. Tyto telefony běží na PhoneOS, který je podporován oběma i. Chcete-li tyto telefony převést na, budete je muset přidatWebex Calling, přiřadit je uživateli nebo pracovnímu prostoru a poté obnovit tovární nastavení telefonů. Pořadí spouštění PhoneOS pro registraci níže ukazuje spouštěcí sekvenci PhoneOS a způsob, jakým se telefon zaregistruje, jakmile bude přidán, i když je telefon stále zřízený a/nebo jsou používány možnosti DHCP (Příklad - 150).

Zaváděcí sekvence PhoneOS pro registraci

podporuje tovární resetování zařízení PhoneOS, aby bylo možné Zero-Touch onboarding. administrátoři mohou vzdáleně obnovit tovární nastavení telefonů 9800 a 8875 prostřednictvím stránek správy CUCM, což eliminuje potřebu fyzického přístupu k telefonům pro zabudování telefonů. Tato funkce je podporována v balíčcích zařízení od 9. září 2025:

CUCM v15 — Unified Communications Manager verze 15

CUCM v14 - Unified Communications Manager verze 14.

Další informace o procesu registrace pro řadu 9800 naleznete v části Proces registrace.

Kromě telefonů Cisco IP může být vyžadováno poskytování dalších zařízení, jako jsou analogové telefonní adaptéry (ATA), bezdrátové telefony (Wifi, DECT), video zařízení, hlasové brány a ^zařízení a telefony třetích stran. Mnoho z těchto zařízení nemá cestu upgrad u firmwaru, jako jsou telefony IP, aby je mohli převést z podnikového firmwaru na cloudový firmware. Proto každé z těchto zařízení zajistíte v Control Hub. Na některé z nich nelze převést a ekvivalentní model je bude muset nahradit (např. ATA 191/192) a další budou vyžadovat ruční rekonfiguraci a/nebo změny softwaru.

Hlasové brány — Informace o migraci místní brány naleznete v tématu Migrace místní brány.
Další informace o konfiguraci hlasové brány VG400, VG410 nebo VG420 v Řídicím centru naleznete v tématu Místní brána

Analogový telefonní adaptér (ATA) - Chcete-li začít s Cisco ATA 191 a 192, přečtěte si Cisco ATA.

Bezdrátový telefon s Wi-Fi — Chcete-li integrovat bezdrátový telefon 840 a 860, přečtěte si článek Integrace bezdrátového telefonu Webex.

Bezdrátové telefony DECT - Chcete-li začít s novou řadou Cisco IP DECT 6800, podívejte se na Cisco IP DECT.

Postup vytváření a správy digitální sítě DECT v Řídicím centru naleznete v tématu Správa sítě DEC T

Další informace o Cisco IP DECT 6800 naleznete v příručce k nasazení

Zařízení a ^telefony třetích stran - Spolu pracujte s dodavateli ^třetích stran na požadavcích na zařízení/telefon a na procesu jejich migrace nebo nahrazení pro podporu.

Konfigurace funkcí

Všechny funkce volání, které jsou vyžadovány, musí být zřízeny před přechodem nebo během přechodu. Jak bylo popsáno v části Migrace uživatelů v dávkách, funkce volání musí být nakonfigurovány a převedeny při přechodu uživatelů, kteří je používají.

Podrobnosti o tom, jak konfigurovat jednotlivé funkce, naleznete v odpovídajících článcích nápovědy ke konfiguraci.

Automatické obsluhy — Chcete-li spravovat automatické obsluhy, přečtěte si článek Automatické obsluhy

Call park - Informace o správě parkování volání naleznete v části Park volání

Vyzvednutí hovorů — Chcete-li nakonfigurovat skupinu vyzvednutí hovorů, přečtěte si článek Vy zved nutí hovorů

Fronty volání — Postup konfigurace fronty hovorů naleznete v tématu Fronta volání

Lovecké skupiny — Informace o správě loveckých skupin naleznete v tématu S práva lovecké skupiny

Provozní režimy — Informace o směrování hovorů na základě provozních režimů viz Smě rování hovorů na základě provozních režimů

Stránkovací skupiny — Postup konfigurace stránkovací skupiny naleznete v tématu Konfigurace stránkovací skupiny

Záznamy - Informace o správě nahrávání hovorů naleznete v části S práva nahrávek

Dosah jednoho čísla — Chcete-li konfigurovat dosah jednoho čísla (kdekoli v kanceláři), přečtěte si článek Konfigurace jednoho čísla

Skupina hlasové schránky — Informace o správě sdílené hlasové schránky a příchozích faxů naleznete v tématu Správa hlasové schránky.

Přijímací zkoušky

Přijímací testování zajišťuje, že migrované prostředí splňuje funkční požadavky, funguje podle očekávání a poskytuje bezproblé mové uživatelské prostředí napříč všemi komunikačními pracovními postupy. Tento proces ověřování je mnohostranný a pokrývá vše od zřizování uživatelů a přiřaz ení čísel až po provozní výkon pokročilých funkcí volání .

Tato část poskytuje příklady a zdůrazňuje klíčové aspekty, které je třeba vzít v úvahu během akceptačního testování; nicméně, nemá sloužit jako vyčerpávající nebo komplexní kontrolní seznam.

Zřizování uživatelů a přiřazení čísel

Základním aspektem akceptačního testování je ověření, že všichni uživatelé jsou přesně a kompletně zřízeni uvnitř. To vyžaduje důkladné srovnání mezi adresářem source () a nově vytvořenou uživatelskou základnou, aby bylo zajištěno, že každý uživatelský účet spolu s přidruženými atributy, jako jsou čísla rozšíření a přiřazení přímého vnitřního vytáčení (DID), byly správně migrovány. Úplnost zajišťování je rozhodující nejen pro provozuschopnost prvního dne, ale také pro průběžnou správu a podporu.

Ověření přiřazení čísel zahrnuje potvrzení, že každému uživateli je přiřazena správná přípona a externí číslo a že tato čísla směrují správně jak v interních (on-net), tak externích (PSTN) tocích volání. Je nezbytné zkontrolovat případné překrývání, chybějící přiřazení nebo nesprávné konfigurace, které by mohly vést k chybám směrování hovorů nebo přerušení služby.

PSTN toky hovorů a prezentace ID volajícího

Robustní postup akceptačního testování musí zahrnovat end-to-end validaci toků volání PSTN. To zahrnuje scénáře příchozích i odchozích ho vorů. U příchozích hovorů PSTN by měl testovací tým potvrdit, že hovory jsou doručovány do zamýšlených koncových bodů, ať už se jedná o jednotlivé uživatele, fronty hovorů, skupiny hledání nebo automatické obsluhy. Odchozí hovory PSTN musí být uskutečněny úspěšně, se zvláštním důrazem na správné doručení a prezentaci informací o ID volajícího. To zahrnuje zajištění toho, aby bylo externím příjemcům zobrazeno správné jméno a číslo vol ajícího v souladu s organizačními zásadami a regulačními požadavky.

Testování by mělo také řešit scénáře převzetí služeb při selhání, jako je zpracování nedosa žitelných koncových bodů nebo narušení sítě. To pomáhá potvrdit, že záložní mechanismy a alternativní směrování fungují správně, udržují kontinuitu a spolehlivost služeb.

Toky hovorů v síti

Interní nebo on-net toky hovorů tvoří páteř podnikové komunikace. Testování akceptace v této oblasti ověřuje, zda jsou hovory mezi uživateli v rámci organizace směrovány správně, přičemž funkce, jako je přenos hovorů, pozastavení, přesměrování a konference, fungují podle plánu. Musí být potvrzena integrita čí selných plánů, připojení mezi rozšířením a podporou zásad organizačních volání.

Uživatelské zpracování hovorů a ověření funkcí

Důležitým aspektem akceptačního testování je ověření toho, jak uživatelé zpracovávají hovory pomocí a podpor ovaných stolních telefonů. Tento proces se zaměřuje na potvrzení, že každodenní pracovní postupy volání jsou intuitivní a spolehlivé, a že uživatelé mají bezproblémový přístup k základním funkcím nezbytným pro jejich role. Testování by mělo posoudit snadnost, s jakou mohou uživatelé uskutečňovat a přijímat hovory, spravovat funkce zadržení a obnovení a provádět naslepo i konzultační převody. Je také nezbytné ověřit, zda jsou přesměrování ho vorů, konference a další pokročilé funkce, jako je parkování a načítání hovorů nebo aktivace funkce Nerušit, snadno dostupné a fungují hladce.

Zkušenosti by měly být vyhodnoceny z hlediska jasnosti a odezvy s ohledem na to, jak uživatelé interagují s historií hovorů, hlasovou schránkou a integrovanými adresáři. Další pozornost by měla být věnována schopnosti přesouvat aktivní hovory mezi zařízeními a efektivně používat ovládací prvky hovoru v rámci aplikace nebo na fyzických telefonech. Koneč ným cílem je zajistit, aby prostředí koncového uživatele bylo konzistentní, efektivní a plně podporovalo komunikační potřeby organizace po migraci.

Volací fronty: Zkušenosti s agentem a supervizorem

Fronty hovorů se často používají pro zpracování scénářů příchozích hovorů s velkým objemem. Přijímací testování se zde zaměřuje na několik dimenzí. Nejprve je třeba ověřit, že volání jsou distribuována agentům podle nakonfigurované logiky fronty, jako je round robin, nejdelší nečinnost nebo simultánní vyzvánění. Prezentace hovorů ve frontě na desktopech agentů musí být zkontrolována z hlediska přehlednosti a snadnosti použití, aby bylo zajištěno, že agenti mohou efektivně přijímat, zadržovat a přenášet hovory.

Pro supervizory by prostředí počítače mělo být vyhodnoceno z hlediska funkcí, jako je monitorování v reálném čase, nabízení hovorů a analýza nebo přehled o výkonu fronty. To zahrnuje mimo jiné ověřování řídicích panelů a nástrojů pro vytváření sestav, které poskytují použitelná data o distribuci hovorů, aktivitě agenta a metrikách fronty.

Hunt Groups: Distribuce hovorů

Skupiny lovu jsou klíčovým mechanismem pro distribuci hovorů předdefinovaným skupinám uživatelů. Přijímací testování musí potvrdit, že hovory jsou směrovány členům skupiny na základě nakonfigurovaného loveckého algoritmu a že scénáře přetečení, přesměrování a bez odpovědi jsou zpracovávány podle návrhu. Zajištění toho, aby chování členství ve skupině a směrování hovorů odpovídalo těm, které byly dříve stanoveny, je zásadní pro provozní konzistenci a spokojenost uživatelů.

Automatické obsluhy: Oznámení a operace nabídek

Automatické obsluhy představují přední linii automatizovaného zpracování hovorů. Testování musí zahrnovat přehrávání oznámení, přesnost zaznamenaných pozdravů a správnou funkci stromů nabídek. Výběr nabídky by měl spolehlivě směrovat volající na příslušná oddělení, jednotlivce, nebo externí čísla. Testování by také mělo zahrnovat neplatné scénáře nebo scénáře časového limitu, aby se potvrdilo, že volající dostávají jasné pokyny nebo jsou přesměrováni podle plánu.

Provoz hlasové schránky

Konečně, funkce hlasové schránky je rozhodující pro uživatelskou zkušenost. Přijímací testy by měly ověřit, zda jsou hlasové schránky správně přiřazeny a přístupné, a to jak z organizace, tak vzdáleně. Schopnost zaznamenávat, načítat a spravovat zprávy musí být potvrzena spolu s doručením oznámení.

Optimalizace

Migrace služby PSTN na Cloud Connect pro

Optimalizace místní infrastruktury

Využijte analytiku a řešení problémů

Migrace služby PSTN na Cloud Connect pro

Jakmile jsou všechny koncové body a uživatelé migrováni do cloudového volání, jediným účelem Unified CM je fungovat jako tranzit mezi bránami PSTN a prostřednictvím místní brány. Odstranění brány PSTN a místní brány z obrazu pomocí Cloud Connect jako přístupu PSTN pro všechny Webex Calling uživatele má několik výhod, včetně snížení nákladů a lepší spolehlivosti. Chcete-li převést místní přístup PSTN na Cloud Connect pro , postupujte takto:

Cloud Connect pro výběr partnerů.

Podívejte se na seznam Cloud Connect pro partnery a vyberte si z dostupných partnerů dostupných pro umístění vaší organizace.

Cloud Connect pro ověření.

Před přepnutím přístupu PSTN pro lokality na Cloud Connect je třeba ověřit a ověřit připojení k PSTN prostřednictvím vybraného partnera Cloud Connect. Za tímto účelem je třeba zřídit testovací umístění s ně kterými testovacími uživateli zřízenými v tomto testovacím umístění. Přístup PSTN pro toto testovací místo je poté nastaven na partnera Cloud Connect před ověřením připojení PSTN pomocí testovacích telefonů. Po úspěšném ověření může být testovací umístění zrušen o.

Přenos čísel.

Chcete-li se připravit na přechod na Cloud Connect, je třeba zadat příkaz portů pro všechna čísla aktuálně přiřazená kmenovému portu PSTN, který končí. Všechna čísla musí být přenesena na partnera Cloud Connect. Aby byla zachována dosažitelnost mezi lokacemi, musí být všechna čísla všech míst přenesena současně .

Přepněte na partnera Cloud Connect.

K datu přechodu, přístup PSTN pro všechna umístění v musí být nastaven na poskytovatele služby PSTN připojeného k cloudu, a mělo by být ověřeno příchozí a odchozí připojení.

Jak je popsáno v části PSTN kapitoly návrhu, zákazníci se také mohou rozhodnout přesunout svůj přístup PSTN do Cloud Connect na začátku přechodu pomocí trunkingu PSTN pro hybridní nasazení. Další informace naleznete v tématu trunkování PSTN pro hybridní nasazení. Webex Calling V takovém případě je během přechodu přístup PSTN prostřednictvím místní brány a po přesunutí všech uživatelů neexistuje žádný další krok migrace související s PSTN kromě vyřazení z provozu a místních bran.

Optimalizace místní infrastruktury

Jakmile jsou všichni uživatelé převedeni a všechny koncové body převedeny na cloudovou registraci (nebo byly vy řazeny z provozu), aktualizujte příslušnou místní infrastrukturu nyní, když se používá cloudové volání. Aktualizace infrastruktury zahrnují:

Odeberte místní DNS SRV záznamy řízení hovorů a zpráv z místních server ů DNS včetně serverů cisco_uds. _tcp. <domain>, cup_login. _tcp. <domain>. Tyto záznamy SRV již nejsou potřebné pro zjišťování klientských služeb.

Odstraňte DNS SRV záznamy související s hranami z veřejného systému DNS včetně collab_edge. _tls. <domain>. Tyto záznamy SRV již nejsou vyžadovány pro zjišťování klientských služeb hraničních služeb spolupráce.

Aktualizujte všechny relevantní rozsahy DHCP, abyste odstranili adresy TFTP/spouštěcího serveru možnosti 66 a možnost 150. Tyto rozsahy již nejsou vyžadovány pro zjišť ování a stahování konfigurace řízení volání koncových bodů.

Aktualizovat/odebrat příslušné protějšky v místní bráně/krychli, které směrují hovory do a z. Unified CM Pro místní směrování hovorů již nejsou vyžadovány tyto propojovací moduly.

Odstraňte nebo odeberte všechny virtuální počítače a/nebo servery uzlů clusteru. Podle potřeby přepracujte výpočetní prostředky a hardware . Tyto prostředky již nejsou potřebné pro řízení hovorů a hraniční služby.

Odstraňte nebo odeberte všechny virtuální počítače a/nebo servery uzlů clusteru. Podle potřeby přepracujte výpočetní prostředky a hardware . Tyto prostředky již nejsou potřebné pro hlasovou schránku a služby jednotných zpráv .

Vyčištění: Po migraci přístupu PSTN na Cloud Connected PSTN lze vyřadit kmeny PSTN, brány PSTN a místní bránu z provozu.

U jakéhokoli stávajícího místního řešení E911 odstraňte všechna umístění nebo čísla, která byla migrována, a jakmile je úplný přechod dokončen, odeberte virtuální počítače nebo servery aplikace. Podle potřeby přepracujte výpočetní prostředky a hardware . Tyto zdroje již nejsou potřebné pro tísňové volání a lokalizační služby.

DNS patřící migrovaným uživatelům by měly být umístěny do skrytého oddílu, aby se zabránilo selhání směrování hovorů a aby se zajistilo, že všechny CSS mají prioritní přístup k cloudové cestě stejných DNS.

Aktualizujte fyzickou odesílatelnou polohu a síťový prvek v horizontu mobility, kdykoli dojde ke změnám. Běžné činnosti, které vyžadují aktualizace, jsou:

Výměna síťového přepínače

Výměna bezdrátového přístupového bodu

Změny rozsahu DHCP

Fyzické změny uvnitř budovy (pokud se řeší na kubickou/kancelář)

Rozšíření nebo zmenšení fyzického kancelářského prostoru uvnitř budovy.

Využijte analytiku a řešení problémů

poskytuje komplexní funkce analýzy a odstraňování problémů, které vám pomohou vizualizovat a sledovat nasazení. Ty zahrnují kvalitu médií, podrobnou historii hovorů, frontu hovorů, lo veckou skupinu a analýzu automatické obsluhy. Příklad analýzy kvality médií je uveden na obrázku analýza kvality médií.

analýza kvality médií

V části Odstraňování problémů lze zobrazit každý hovor uskutečněný pomocí s podrobnými informacemi o klíčové kvalitě médií a problémech souvisejících se signalizací, které pomohou určit problémy s médii i neúspěšnými hovory, jak je znázorněno na obrázku Odstraňování problémů s kvalitou médií.

řešení problémů s kvalitou médií

Řešení problémů lze také integrovat s dalšími produkty Cisco, jako jsou přepínače ThousandEyes a Meraki, a poskytnout tak ještě bohatší integrovaný zážitek v Control Hub. Další informace o používání Webex Callinganalytiky a odstraňování problémů naleznete v tématu Řešení potíží Webex Calling s hovory v centru Control Hub.

Úvod

Než začnete

Přehled

Základní komponenty

Přehled procesů PPDIO

Obecný popis PPDIO

Použití PPDIO pro Webex Calling migr Unified CM aci projektů

Připravit

Plán

Návrh

Implementovat

Optimalizace

PPDIO zpětnovazební smyčky

Migrační přístup

Než začnete

Tato příručka je určena pro týmy nebo jednotlivce se zkušenostmi s konfigurací a Cisco Unified Communications Manager správou (Unified CM) a koncových bodů Cisco, včetně stolních telefonů IP, video zařízení a softwarových klientů Jabber. V tomto dokumentu jsou odkazy na produktovou a podpůrnou dokumentaci, které vám pomohou.

Tento dokument se zaměřuje pouze na přechody z Unified CM na Webex Calling více nájemců. Termín Webex Callingv tomto dokumentu vždy odkazuje na Webex Calling více nájemců.

Před zahájením migrace z Unified CM doWebex Calling, je nezbytné mít komplexní pochopení Webex Calling řešení a jeho příslušných komponent. Úspěšná migrace vyžaduje znalost Webex Calling architektury, modelů služeb, možností nasazení a souvisejících funkcí, aby bylo možné správně mapovat stávající Unified CM úlohy a navrhnout efektivní plán přechodu.

Důkladné pochopení následujících Webex Calling složek je nezbytné pro informování o účinné strategii přechodu a provozní připravenosti.

Řídicí rozbočovač

Zřizování adresářů a uživatelů

Webex Callingnástupiště

Podporované koncové body volání

Možnosti připojení PSTN

Webex Callingvytáčecí plán a správa čísel

Funkce zabezpečení a dodržování předpisů.

Další informace naleznete v tématu Cisco Preferred Architecture forWebex Calling.

Tato příručka zvýrazní nástroje a procesy, které je třeba použít během celého životního cyklu přechodu. Přechod z místního volání na novou platformu cloudových volání však může být značným ú Webex Calling silím s potenciálními obchodními, technickými a složitými výzvami. Unified CM K překonání těchto problémů má společnost Cisco k dispozici několik různých možností, které vám pomohou s vaší cestou. Je důležité zkontrolovat informace na stránce Enterprise cloud Calling — Migrace volání a porozumět každé možnosti a jak vám může každá z nich pomoci s vaší vlastní migrací.

Nástroje pro migraci Webex: samoobslužné bezplatné nástroje zabudované do centra Control Hub, které zefektivňují váš přechod na Webex Calling

Certifikovaní poskytovatelé migrace: Poskytovatelé softwaru a nástrojů ověřovaní společností Cisco, kteří vyvinuli řešení migrace, která pomáhají partnerům a zákazníkům Webex při složitých a rozsáhlých migracích. Tato řešení mohou pomoci zjednodušit, řídit a urychlit přechod na Webex Calling

Webex Setup Assist: služba migrace vedená společností Cisco, která provede zákazníky a partnery Webex Calling nasazením a konfigurací, které jsou potřebné k úspěšné migraci Unified CM uživatelů a služeb. Webex Calling

Přehled

S růstem cloudových služeb spolupráce se stále více zákazníků snaží přesunout své stávající pracovní zatížení spolupráce do cloudu vzhledem k slibům snížení celkových nákladů na vlastnictví, zjednodušené správy, nepřetržitého poskytování funkcí, zvýšeného škálování a vynikající spolehlivosti, které jsou vlastní cloudovým službám. Vzhledem k tomu, že zákazníci hledají přechod z místních služeb na služby cloudové spolupráce, je důležité, aby pochopili, co přechod obnáší, a kroky potřebné k provedení přechodu.

Účelem tohoto dokumentu je poskytnout pokyny k nasazení zákazníkům, kteří konkrétně chtějí přejít z místního prostředí Unified CM Webex Calling do cloudu. Tato příručka nasazení předpokládá, že čtenář má základní znalosti o přechodu volání mezi Unified CM aWebex Calling, včetně toho, jaké změny při provádění tohoto přechodu a jaké jsou rozdíly při přesouvání pracovní zátěže volání z místního prostředí do cloudu. Než budete pokračovat, ujistěte se, že jste zkontrolovali a znáte informace dostupné v mapě přecho du. Tento dokument mapy přechodu poskytuje informace o změnách a rozdílech tohoto přechodu.

Jak je znázorněno na obrázku Architektura místní spolupráce: řízení hovorů a vzdálený přístup, typické místní nasazení zahrnuje různé komponenty infrastruktury pro spolupráci v síti, platformu pro řízení hovorů, hraniční platformu, hardwarové a softwarové kon cové body a v některých případech dokonce platformy pro konference a plánování. V architektuře Cisco by to zahr Unified CM novalo řízení hovorů, Expressway pro vzdálený přístup a hraniční služby mezi podniky (B2B), Cisco Meeting Server/ Cisco Meeting Management pro místní konference, Unity Connection pro hlasové zprávy a uživatelský hardware (Cisco IP Phones, Cisco Desk and Room video systémy) a software () koncové body založené na IP. Cisco Jabber Tyto komponenty se mohou v některých prostředích mírně lišit, ale toto je výchozí bod pro přechod popsaný ve zbytku tohoto dokumentu.

Architektura místní spolupráce: řízení hovorů a vzdálený přístup

Architektura znázorněná na obrázku Archit ektura místní spolupráce: řízení volání a vzdálený přístup je založena na preferované architektuře (PA) pro nasazení Cisco Collaboration Enterprise On-Premises Deployments. Další informace o prostředí Enterprise On-premise naleznete v tématu Preferované architek tury spolupráce společnosti Cisco.

Dří Webex Calling ve: Tabulka komponent místní volající infrastruktury uvádí klíčové prvky místní architektury před přechodem do clou du.

Tabulka 1. Dříve: Komponenty místní volající infrastruktury
Výrobek Popis

Unified CM Místní řízení hovorů poskytující služby registrace zařízení a směrování hovorů

Cisco Expressway-C/E Edge infrastruktura poskytující funkce Mobile a Remote Access (MRA) a business-to-business (B2B) umožňující vzdáleným koncovým bodům zabezpečené připojení mimo organizaci. Expressway je nasazena ve dvojicích, aby poskytovala průjezd brá nou firewall pro externí koncové body.

Cisco Meeting Server (CMS), Cisco Meeting Management (CMM) a Cisco TelePresence Management Suite (TMS) Místní infrastruktura hlasových, video a webových konferencí poskytující vícebodové schůzky, správu schůzek a možnosti plánování. [Volitelné]

Cisco Unity Connection Místní platforma hlasových zpráv poskytující hlasovou schránku a funkce sjednoceného zasílání zpráv. [Volitelné]

Cisco Desk, Cisco Room, Cisco Board, Cisco IP telefony a Cisco Jabber Zařízení založená na protokolu IP registro Unified CM vaná a poskytující hlasové hovory a videohovory

Jak je znázorněno na obrázku Rozhodnutí o přechodu: místní volání na Webex Calling, zákazníci, kteří mají místní řízení hovorů s koncovými body stolních Unified CM a video IP koncových bodů, mají na výběr přechod architektury na cloudovou architekturu. Webex Calling

Rozhodnutí musí být učiněno na základě požadavků zákazníka na funkčnost. Zákazníci, kteří mají následující požadavky, by měli před přijetím tohoto rozhodnutí pečlivě zvážit a nakonec se mohou rozhodnout ponechat kontrolu hovorů v místním prostředí:

Modely telefonů nepodporované Webex Calling

Komplexní nebo četné integrace s jinými místními systémy nebo řešeními, zejména tam, kde je replikace těchto integrací obtíž Webex Calling ná nebo nejsou k dispozici žádná ekvivalentní alternativní řešení

Komplexní číselný plán, vysoce podrobné třídy služeb nebo obojí

Omezený, omezený nebo nespolehlivý přístup k internetu

Přísné zásady ochrany osobních údajů a vlastnictví

Požadavek na shodu pro nahrávání a ukládání médií na místě nebo v zemi

Integrace třetích stran bez životaschopné alternativní Webex Calling integrace

Integrace kontaktních center, kde se kontaktní centrum inter zatím nepřesouvá do clou du.

Rozhodnutí o přechodu: místní volání Webex Calling
Zákazníci, kteří chtějí začít využívat služby cloudových volání, by měli zvážitWebex Calling. Tato cloudová služba volání umožňuje zákazníkovi využít globální architekturu Webex pro škálování a konektivitu. Účastníci podnikové sítě a vzdálení účastníci mimo podnikovou síť mohou komunikovat pomocí hardwarových koncových bodů založených na IP a/nebo desktopových nebo mobilních softwarových klientských aplikacích.

Tento dokument se zaměřuje na zákazníky s nasazením řízení Unified CM volání, kteří chtějí porozumět obecným krokům, úvahám a požadavkům na povolení Webex Calling nasazení, jak je uvedeno v následující části.

Základní komponenty

Cílová architektura pro tuto migraci obsahuje několik nových komponent. To zahrnuje Webex Calling službu pro cloudové volání, aplikaci Webex, Cisco Directory Connector pro integraci identit a Local Gateway (LGW) pro přístup PSTN, jakož i integraci místního volání do cloudu. Plány volání Cisco nebo Cloud Connected PSTN (CCP) zprostředkované Cloud Connect pro Webex Calling partnery jsou další možnosti přístupu k PSTN.

Jak je znázorněno na obrázku Po: Webex Calling Architektura, nové komponenty (adres Webex Calling ářový konektor, místní brána a brána přežití) jsou přidány do stávajícího místního nas azení.

Po: Webex Calling Architektura

Po: Tabulka komponent infrastruktury volání clou du uvádí nové prvky architektury po přechodu na Webex.

Tabulka 2. Po: Komponenty infrastruktury cloudových volání
Výrobek Popis

Webex Calling Cloudová služba volání poskytovaná z platformy Webex poskytující registraci koncového bodu a směrování hovorů

Adresářový konektor Cisco Aplikace systému Windows běžící na počítači s doménou Windows poskytující synchronizaci identit mezi místním podnikovým úloži Active Directory štěm a úloži štěm identit organizace Webex.
Pro zákazníky, kteří přecházejí z míst Active Directory ního prostředí na Entra ID, integrace identity s Webex namísto Cisco Directory Connector používá aplikaci Průvodce identifikací Entra ID.

Místní brána Místní brána funguje jako most mezi místní jednotnou komunikační sítí zákazníka a Webex Calling cloudem. Může být nasazen místně nebo hostován partnerem a poskytuje přístup PSTN pro koncové body registrované v cloudu a integraci volání mezi Unified CM registrovanými a cloudovými koncovými body. Cisco IOS-Směrovač integrovaných služeb XE (řady ISR 1100 a 4000), řada Cisco Catalyst 8200/8300, software Cisco Catalyst 8000V Edge a různé certifikované hraniční kontroléry session (SBC) třetích stran lze použít jako LGW pro přístup postupné migrace.

Brána pro přežití Survivalability Gateway (SGW) je brána založená na lokální síti IOS-XE, která poskytuje služby záložního volání koncovým bodům na místě Webex Calling během výpadků sítě.

Plán volání Cisco, Cloud Connect pro Webex Calling Cisco Calling Plan a Cloud Connect for Webex Calling jsou cloudové možnosti přístupu PSTN pro koncové body. Webex Calling Přístup PSTN je usnadněn poskytovatelem cloudového PSTN a nevyžaduje žádné místní vybavení.

Aplikace Webex Klientská aplikace běžící na desktopovém OS (Windows, Mac) nebo mobilním OS (Android, iOS) a registrovaná přímo na Webex Calling platformu pro funkčnost volání.

Přehled procesů PPDIO

Proces PPDIO znamená připravit, plánovat, navrhnout, implementovat a optimalizovat. Jedná se o strukturovanou metodiku společnosti Cisco, která řídí projekty od počátečního hodnocení přes neustálé zlepšování a zajišťuje efektivní a úspěšné nasazení nebo migrace.

Proces PPDIO

Obecný popis PPDIO

Příprava: Posoudit současné prostředí, shromáždit požadavky a sladit zúčastněné strany, abyste vytvořili pevný základ.

Plán: Vypracujte podrobné plány projektů včetně časových os, zdrojů a strategií zmírňování rizik.

Návrh: Navrhněte cílové řešení přizpůsobené obchodním a technickým potřebám.

Implementace: Proveďte nasazení nebo migraci podle návrhu, ověřte funkčnost a výkon.

Optimalizace: Průběžně zlepšujte řešení po implementaci monitor ováním výkonu, zdokonalováním konfigurací a využitím automatizačních a integračních nástrojů.

Použití PPDIO pro migrační projekty Unified CM na Webex Calling

Při přechodu z Unified CM naWebex Calling, proces PPDIO poskytuje jasný plán pro zajištění hladkého a efektiv ního přechodu:

Připravit

Posoudit stávající Unified CM prostředí a připravenost na migraci

Shromažďujte podrobná data o uživatelích, zařízeních, síti a závislostech

Shromažďujte podrobnosti o poloze včetně adresy reakce na mimořádné události, počtu uživatelů, přístupu k internetu, přístupu PSTN

Identifikujte rizika a definujte rozsah projektu, abyste sladili všechny zúčastněné strany.

Plán

Vytvořte komplexní plán migrace s dávkovými plány, přiřazením zdrojů a časovými osami

Definujte úkoly, jako je upgrade firmwaru zařízení, poskytování licencí a přihlášení uživatele

Koordinujte migrační okna se společností Cisco a partnery, abyste minimalizovali narušení provozu.

Návrh

Mapování aktuálních Unified CM konfigurací, číselných plánů a uživatelských profilů na Webex Calling ekvivalenty

Navrhněte Webex Calling prostředí, včetně strategie PSTN (prozatímní a konečná), umístění, uživatelské role a integrační body, jako je místní brána (CUBE) a synchronizace adresářů

Plánujte scénáře koexistence, kde Unified CM a Webex Calling fungují současně během migrace.

Implementovat

Pomocí nástrojů pro migraci Control Hub spolu s nástroji třetích stran můžete provádět změny režimu firmwaru zařízení, konfiguraci funkcí a migraci uživatelů

Využijte hromadné operace a zřizování pomocí rozhraní API Webex pro zjednodušení rozsáhlých migrací a konfigurací

Provádění zřizování licencí, registrace zařízení a aktualizace konfigurace

Ověřte úspěšnost migrace pomocí testování a provoz ního ověření.

Optimalizace

Průběžně sledu Webex Calling jte výkon a uživatelskou zkušenost

Upřesněte konfigurace a pracovní postupy na základě provozních dat a zpětné vazby

Využijte možnosti automatizace a integrace ke zvýšení efektivity a škálovatelnosti

Podle potřeby vyřazujte starší Unified CM komponenty z provozu a poskytněte průběžnou podporu pro operace v den 2.

Tento vylepšený přístup PPDIO zajišťuje řízenou, transparentní a efektivní migraci z Unified CM doWebex Calling, s využitím nástrojů, rozhraní API a partnerského ekosystému společnosti Cisco k udržení kontinuity podnikání a zlepšení možností spolupráce.

PPDIO zpětnovazební smyčky

Přehled na vysoké úrovni zobrazený v Iteracích obrázků při provádění PPDIO ilustru je jednu zpětnovazební smyčku od optimaliz ační fáze zpět do fáze přípravy. To znamená, že po počáteční implementaci existuje neustálá příležitost k neustálému zlepšování. Každý cyklus optimalizace může identifikovat nové požadavky nebo oblasti pro vylepšení, které lze řešit prostřednictvím následných projektů nebo iniciativ. Tyto jednotlivé projekty zase sledují zavedený životní cyklus PPDIO (Prepare, Plan, Design, Implement, Optimize). Tento iterativní přístup zajišťuje, že systém zůstane v souladu s vyvíjejícími se obchodními cíli a technologickým pokrokem a podporuje kulturu neustálého zdokonalování a přizpůsobivosti.

Iterace při provádění PPDIO

Během provádění procesu PPDIO, je běžné, že zjištění v pozdějších fázích vyžadují přehodnocení a potenciálně revi zi rozhodnutí učiněných v dřívějších fázích. Například problémy, ke kterým došlo během fáze provádění, jako je identifikace nejasností návrhu nebo chybějících podrobností, mohou odhalit, že určité aspekty nebyly během fáze návrhu plně vyřešeny. V takových případech je nutné před pokračováním opakovat zpět do příslušné dřívější fáze, aby se tyto problémy vyřešily. Tento iterativní mechanismus zpětné vazby, jak je znázorněno v procesu PPDIO Unified CM s podporou obrázku, zajišťuje, že řešení je důkladně ověřeno a zdokonaleno, což v konečném důsledku přispívá k robustnějšímu a efektivnějšímu nasazení.

Unified CMasistovaný proces PPDIO

Při přechodu z Unified CM naWebex Calling, každá fáze procesu PPDIO může významně těžit z informací shromážděných ze stáv ajícího Unified CM prostředí. Z aktuální Unified CM konfigurace lze například extrahovat komplexní inventáře uživatelů, telefonních čísel, funkcí volání a komponent číselného plánu. Tato data doplňují informace poskytované přímo zúčastněnými stranami a pomáhají zefektivnit plánování a projekční činnosti. Využití vhodných nástrojů k automatizaci extrakce a analýzy dat nejen zvyšuje přesnost, ale také urychluje celkový proces. Využitím poznatků ze stávajícího nasazení Webex Calling může být přechod proveden efektivněji než tradiční implementace greenfield, při současném dodržování strukturované metodiky PPDIO. Tento proces je znázorněn v procesu PPDIO Unified CM s podporou obrázku.

Migrační přístup

Při plánování přechodu z místního prostředí Unified CM naWebex Calling, musíte určit, jak k této cestě přistupujete. Nejprve se budete muset rozhodnout, zda bude migrace probíhat flash-cut (vše najednou) nebo postup ný přístup (migrace skupin uživatelů/zařízení po delší dobu).

Provádění migr ace typu flash přesune všechny vaše uživatele a zařízení nejrychleji. Pomocí této metody přesunete všechny uživatele a zařízení z míst Unified CM ního Webex Calling prostředí současně. V podstatě se jedná o jediné migrační okno pro všechny uživatele a zařízení. Po dokončení této migrace budou všichni vaši uživatelé a zařízení na Webex Calling platformě a veškerá vaše Unified CM infrastruktura může být vyřazena z provozu. Mnoho organizací však tento přístup nemůže použít kvůli rozsahu a velikosti nasazení volání.

Druhým přístupem je postup ná migrace. Většina organizací tento přístup použije, protože poskytuje lepší kontrolu, správu a škálování s migrací. Je také vhodnější pro větší nasazení a/nebo nasazení UC ve více oblastech. Proto, tento dokument se zaměřuje na postupný přístup se dvěma kroky přechodu.

Jak je znázorněno na následujícím obrázku Postupný přechod volání: Hybridní a cloud, první fáze přechodu (fáze 1) vede k nasazení koexistence s duálními vol acími prostředími. V této fázi dochází k přechodu na některé uživatele, zařízení a softwarové klienty, Webex Calling zatímco jiní jsou stále na místním řízení ho Unified CM vorů. Konečná fáze přechodu (fáze 2) má za následek čistě cloudové volání prostředí, kde byli všichni uživatelé, zařízení a měkcí klienti plně převedeni na Webex Calling platformu.

Jak dlouho trvá, než organizace zcela přejde na cloudové volání, se bude lišit v závislosti na aktuálním nasazení. V některých případech může organizace provést počáteční přechod a zůstat ve fázi řízení dvojího volání (fáze 1) po delší dobu (měsíce nebo dokonce roky), zatímco v jiných případech může organizace plně přejít na Webex Calling (fázi 2) ve velmi krátkém období (týdny nebo měsíce). Tento dokument je určen k pokrytí obou fází (fáze 1 - koexistence a fáze 2 - plně přechodná).

Postupný přechod volání: hybridní a cloudové

Je možné, že některé organizace mohou udržovat koexistenční nasazení řízení duálního volání neomezeně dlouho bez plánů na úplný přechod na cloudové volání.

Druhým hlediskem je, jak přesunete uživatele, zařízení a softwarové klienty z míst ního řízení hovorů na řízení cloudových hovorů. Doporučený přístup je třífázový přechod . Obrázek Doporučený třífázový přechod níže rozděluje tento přístup do 3 fází.

Doporučený třífázový přechod

Předmigrace: Tato fáze se zaměřuje na přípravu Webex i Unified CM prostředí pro migraci. Nejde o volání konkrétního plánování nebo konfigurace a zaměřuje se na dokončení činností, které lze provést nyní a před zahájením jakéhokoli projektu Webex Calling migrace. Cílem je vybudovat základ pro obě prostředí pro přípravu na migraci.

Příprava na migraci: V této fázi začíná úsilí o přípravu na migraci do Webex Calling. Zde je třeba přezkoumat a aktualizovat obchodní a technické požadavky. Neprovádějte jen zved ání a přesun toho, co je v současné době nasazeno, ale místo toho předefinujte obchodní a technické požadavky, které vaše společnost potřebuje dnes i v budoucnu, využitím síly. Unified CM Webex Calling Kromě toho je to fáze, kdy dokončíte svůj návrh, plánování konfigurace a plánování/plán migrace.

Migrace (zavádění a vyřazení z provozu): V této fázi dochází ke skutečné migraci uživatelů, zařízení, telefonních čísel a softwarových klientů. Jak bylo uvedeno výše, lze tuto fázi dokon čit pro každého najednou (flash-cut) nebo přes více oken změn (fáz ový řez). Plány přijetí koncových uživatelů, školení, a komunikace jsou zásadní, takže vaši uživatelé jsou si vědomi změn, jak používat novou platformu pro volání, a věděli, kdy ke změně dojde. Posledním krokem je vyřazení veškeré místní infrastruktury UC , která se již nepoužívá.

Fáze před migrací obsahuje aktivity (povinné, doporučené a volitelné), na kterých můžete okamžitě začít pracovat. Doporučujeme je dokončit dříve než později a nejlépe před zahájením projektu. Dokončení některých činností může trvat déle, proto jejich dřívější spuštění pomůže zefektivnit váš skutečný projekt migrace.

Níže uvedený obrázek Čin nosti před migr ací zdůrazňuje pět konkrétních kategorií činností, které souvisejí s Webex Calling migrací.

Předmigrační činnosti

Připravit

Obchodní a technické požadavky

Proč je shromažďování požadavků důležité:

Obchodní požadavky

Technické požadavky

Připravenost a požadavky na síť

Nastavení cloudové sítě UC

Posouzení současného prostředí

Licencování

Místa/Stránky

Inventarizace stávajících zařízení/klientů

Ověřte způsobilost zařízení

Uživatelé

Připojení PSTN

Funkce a využití funkcí

Integrace společnosti Cisco: Unity Connection UCCX UCCE

Nahrávání hovorů

Integrace třetích stran

Obchodní a technické požadavky

Při plánování migrace z do je zásadní během fáze plánování důkladně shromáždit technické i obchodní požadavky. Tento krok zajišťuje, že migrace bude v souladu s provozními cíli a technickými mož nostmi vaší organizace a minimalizuje rizika a přerušení provozu.

Proč je shromažďování požadavků důležité:

Sladí obchodní cíle: Por ozumění obchodním potřebám pomáhá přizpůsobit migraci tak, aby podporovala klíčové pracovní postupy, uživatelské prostředí a plány růstu.

Zajišťuje technickou kompatibilitu: Včasná identifikace technických požadavků zabraňuje problémům s integrací se stávající infrastrukturou, sítí a koncovými body.

Usnadňuje plánování zdrojů: Jasné požadavky pomáhají přesně odhadnout časové osy, náklady a potřebné zdroje.

Snižuje rizika: V časné odhalení potenciálních problémů umožňuje proaktivní řešení, snižuje prostoje a přerušení služeb.

Obchodní požadavky

Mezi typické obchodní požadavky patří:

Počet uživatelů a umístění, které mají být migrovány

Požadované funkce a služby (například směrování hovorů, hlasová schránka, konference, automatická obsluha, fron ty hovorů)

Zásady dodržování předpisů a zabezpečení

Rozpočtová omezení a očekávání nákladů

Potřeby školení a podpory uživatelů

Časová osa migrace a úvahy o kontinuitě podnikání.

Shro mažďování požadovaných funkcí a služeb je kritickým krokem k zajištění toho, aby nový systém splnil obchodní potřeby. Při shromažďování těchto požadavků je důležité nejen zvážit, co je aktuálně nakonfigurováno, ale pokusit se shromáždit skutečné požadavky od obchodních subjektů, které budou systém používat . V opačném případě existuje riziko, že plán bude založen na dlouhodobých předpokladech. Nezapomeňte vyhodnotit další nebo vylepšené funkce dostupné v něm, které nemusí existovat, například volání na cloudu, pokročilé fronty hovorů, , a. To pomáhá při plném využití výhod cloudové platformy.

Při vyhodnocování aktuální konfigurace v, je důležité si uvědomit, že ne všechna stávající nastavení mohou zůstat nezbytná kvůli vyvíjejícím se požadavkům během celého životního cyklu systému. Důraz by měl být kladen na identifikaci a zachování pouze těch konfigurací, které odpovídají současným a budoucím potřebám nasazení.

Zaměřte se více na to, co potřebujete, než na to, co máte.

Zásady dodržování předpisů a zabezpečení jsou rozhodující při migraci z doWebex Calling, aby bylo zajištěno, že nový cloudový komunikační systém bude dodržovat právní, regulační a organizační standardy.

Dodržování předpisů: Organizace musí ověřit, zda splňují odvětvové předpisy, jako jsou GDPR, HIPAA nebo SOX, které řeší požadavky na ochranu osobních údajů, uchovávání a zpracování dat, jakož i mandáty specifické pro jednotlivé země týkající se pobytu dat, obcházení mýtného a lokality médií.

Zabezpečení dat: Zajištění šifrování hlasových a signálních dat při přenosu i v klidu , aby byla chráněna před zachycením nebo neoprávněným přístupem.

Řízení přístupu: Definování a vynucení ověřování uživatelů, autorizace a přístupu založeného na rolích, aby se zabránilo neoprávněnému použití komunikačních prostředků.

Audit a monitorování: Im plementace funkcí protokolování a monitorování pro sledování přístupu a využití pro audity shody a vyšetřování bezpečnostních incidentů.

Sladění zásad: Sladění migrace se stávajícími firemními zásadami zabezpečení, včetně zabezpečení koncových bodů, segmentace sítě a plánů reakce na incidenty.

Zajištění bezpečnosti dodavatele: Vyhodnocení bezpečnostních certifikací společnosti Cisco a osvědčení o shodě s cílem zajistit důvěryhodnost.

Řešení těchto zásad dodržování předpisů a zabezpečení během fáze plánování pomáhá zmírnit rizika, vyhnout se právním sankcím a zachovat integritu a důvěrnost komunikace po celou dobu migrace i po ní.

Potřeby školení a podpory uživatelů jsou základními složkami během migrace z do, aby byl zajištěn hladký přechod a přijetí uživatelů. Mezi klíčové aspekty patří:

Školicí programy: Vytvořte školení na míru pro různé skupiny uživatelů (koncoví uživatelé, administrátoři, pracovníci technické podpory), abyste je seznámili s funkcemi, uživatelskými rozhraními a novými pracovními postupy.

Dokumentace: Poskytujte přehledné a přístupné uživatelské příručky, časté dotazy a rychlé referenční materiály, včetně zdrojů Co je nového a odliš ného a podrobných návodů před a po (ve formátu videa nebo rychlého průvodce), které uživatelům pomohou při přizpůsobení se aktualizovanému prostředí po migraci.

Správa změn: Proaktivně komunikujte změny, abyste spravovali očekávání uživatelů a snížili odolnost.

Struktura podpory: Vytvořte specializovaný tým podpory nebo eskalační cestu, abyste rychle řešili problémy uživatelů během migrace a po ní.

Průběžné vzdělávání: Plánujte průběžné aktualizace školení, jakmile budou vydány nové funkce nebo aktualizace .

Mechanismy zpětné vazby: Implementujte kanály pro uživatele k hlášení problémů a poskytování zpětné vazby ke zlepšení procesů školení a podpory.

Řešení těchto potřeb školení a podpory během fáze plánování pomáhá minimalizovat narušení, zvyšuje důvěru uživatelů, a maximalizuje výhody migrace na.

Technické požadavky

Pro úspěš ný přechod z do země je třeba shromáždit a zdokumentovat několik klíčových technických požadavků, včetně podrobností pro:

Připravenost sítě a kapacita šířky pásma

Komplexní posouzení sítě je zásadní pro zajištění toho, aby vaše stávající infrastruktura mohla podporovat nové Webex Calling prostředí. To zahrnuje:

Analýza šířky pásma: Vyhodnocení současného a předpokládaného využití šířky pásma pro zpracování hlasového, video a datového provozu bez přetížení.

Quality of Service (QoS): Implementace zásad QoS pro upřednostnění hlasového provozu a minimalizaci latence, chvění a ztráty paketů.

WAN a připojení k internetu: O věření, zda připojení WAN a připojení k internetu splňují požadavky na cloudové volání, včetně možností redundance a převzetí služeb při selhání.

Konfigurace brány firewall a NAT: Zajištění, aby nastavení brány firewall a NAT umož ňovalo požadovanou signalizaci a přenos médií pro.

Integrace se stávajícím systémem

Bezproblémová integrace se stávajícími podnikovými systémy je nezbytná pro uživatelskou zkušenost a kontinuitu pracovního postupu:

Adresářové služby: Posouzení integrace s podnikovým adresářem pro automatizované zřizování a ověřování uživatelů.

CRM a obchodní aplikace: Identifikace integračních bodů se systémy řízení vztahů se zákazníky a dalšími kritickými aplikacemi pro podnikání.

Legacy PBX Interworking: Plá nování strategií koexistence nebo postupné migrace, pokud během přechodu zůstanou starší telefonní systémy.

Kompatibilita a zřizování koncových bodů

Všechny koncové body včetně stolních telefonů, softwarových telefonů a mobilních zařízení by měly být vyhodnoceny z hlediska kompatibility :

Podpora zařízení: Pot vrzení, zda jsou stávající IP telefony a zařízení podporovány nebo identifikace požadovaných výměn.

Zřizovací procesy: Zaved ení automatizovaných nebo zjednodušených metod zajišťování pro efektivní začlenění koncových bodů.

Aktualizace firmwaru a softwaru: Plánování nezbytných aktualizací pro zajištění interoperability a zabezpečení.

Konfigurace zabezpečení a standardy šifrování

Bezpečnost je v cloudové komunikaci prvořadá:

Šifrování: Vynucení end-to-end šifrování pro signální a mediální toky v souladu s osvědčenými postupy zabezpečení společnosti Cisco.

Ověřování a řízení přístupu: Impl ementace mechanismů zabezpečeného ověřování (jako je SSO, vícefaktorové ověřování) a granulární kontroly přístupu uživatelů.

Dodržování předpisů: Zajištění, aby řešení splňovalo příslušné regulační a průmyslové standardy (například GDPR, HIPAA).

Monitorování zabezpečení: Integrace s nástroji SIEM a nastavení upozornění na potenciální bezpečnostní incidenty.

Tabulka 1. Příklad hodnocení
Požadavek Klíčové úvahy

Připravenost sítě a šířka pásma Šířka pásma, QoS, WAN/Internet, Firewall/NAT

Integrace se stávajícími systémy Adresář, CRM, pobočková ústředna, e-mail/kalendář

Kompatibilita a zřizování koncových bodů Podpora zařízení, zřizování, aktualizace firmwaru

Konfigurace zabezpečení a šifrování Šifrování, autentizace, dodržování předpisů, monitorování zabezpečení

Školení uživatelů a správa změn Školicí programy, dokumentace, změna komunikace

Přenositelnost čísel a vytáčecí plán Migrace/přenesení čísel, překlad číselného plánu

Integrace třetích stran Stránkování, kontaktní centrum, fax, analogová zařízení

Připravenost a požadavky na síť

Připravenost k síti je rozhodující pro úspěšnou migraci na jakékoli cloudové řešení volání, jako je. Špatné plánování sítě může vést ke zhoršení kvality hovorů, přerušení hovorů a nešťastným uživatelům. Zákazníci musí před migrací provést posouzení sítě. Doporučuje se potvrdit dostupnost šířky pásma sítě pro očekávaný objem hovorů, zajistit splnění požadavků na kvalitu služeb (QoS) a porozumět různým portům, které musí být otevřeny v hraničním bráně firewall.

Spolehlivé síťové připojení s dostatečnou kvalitou služeb (šířka pásma, ztráta paketů, RTT) je základním požadavkem k zajištění nejlepšího možného uživatelského zážitku od začátku do konce pro všechny koncové body, klienty a aplikace schopné hlasu a videa.

Zákazníci a partneři mají přístup k možnostem připojení nad rámec OTT-Internetu (Over-the-Top) , které mohou optimalizovat připojení včetně Webex Edge připojení Connect. Další informace o podrobnostech návrhu Webex Edge služby Connect naleznete v tématu Cisco Preferred Architecture for Webex Edge Connect forWebex Meetings, Calling Multi-Tenant a Dedicated Instance.

Zákazníci mohou využít cScan pro hodnocení sítě, které poskytuje informace o kvalitě sítě zákazníka, kolik hovorů lze navázat, latenci atd. Další informace o nástroji cScan naleznete v tématu Použití nástroje cScan k testování kvality Webex Calling sítě.

Chcete-li zajistit, aby byla síť připravena k migraci, zvažte následující kontrolní seznam:

Plánování šířky pásma

Vypočítejte souběžná volání na web, abyste zajistili dostatečnou šířku pásma pro předcházející a navazující provoz a zahrňte prostor pro další kritický provoz a budoucí růst.

Tabulka výpočtů šířky pásma typu Webex Calling volání zobrazuje typy volání dostupné s nasazením spolu s kodekem a maximální šířkou pásma požadovanou pro každý typ hovoru. Jak je uvedeno v tabulce výpočtů šířky pásma typu ho Webex Calling voru, požadovanou šířku pásma zvukového volání pro každý typ hovoru lze vypočítat pomocí následujícího obecného vzorce:

Počet očekávaných souběžných hovorů* Šířka pásma na hovor založená na kodeku = Požadovaná propustnost sítě.
Tabulka 2. Webex Calling výpočty šířky pásma typu volání
Typy hovorů Kodek - šířka pásma Výpočty šířky pásma
/Stolní telefon -> OPUS - 70 kb/s Počet souběžných hovorů* 70 kbps = Požadovaná propustnost sítě
/Stolní telefon -> Stolní telefon OPUS — 70 kb/s Počet souběžných hovorů* 70 kbps = Požadovaná propustnost sítě
/Stolní telefon -> PSTN přes LGW G.711 — 80 kb/s Počet souběžných hovorů* 80 kbps = Požadovaná propustnost sítě
/Stolní telefon -> PSTN přes Cloud PSTN (např. Plán volání Cisco) G.711 — 80 kb/s Počet souběžných hovorů* 80 kbps = Požadovaná propustnost sítě
/Stolní telefon -> Enterprise přes LGW G.722 — 80 kb/s Počet souběžných hovorů* 80 kbps = Požadovaná propustnost sítě
/Stolní telefon -> hlasová schránka OPUS — 70 kb/s Počet souběžných hovorů* 70 kbps = Požadovaná propustnost sítě

Sčítáním souběžné požadované propustnosti sítě na typ hovoru lze určit celkový potenciální požadavek na šířku pásma pro konkrétní lokalitu.

Všechny nohy volání jsou vždy ukotveny na přístupových SBC. K určení požadované šířky pásma internetu pro jakékoli dané místo je třeba vzít v úvahu nejen interlokační hovory, ale také volání uvnitř umístění a volání do a z místní brány v tomto místě. Například hovor uvnitř webu mezi dvěma telefony MPP by vyžadoval plný duplex až 2 x 70 kb/s na přístupu k internetu dané lokality.

Tabulka příkladů výpočtu Webex Calling šíř ky pásma ukazuje příklad úplného cvičení výpočtu šířky pásma za předpokladu, že všechna zařízení jsou na stejném místě.
Tabulka 3. Webex Calling příklady výpočtu šířky pásma
Typy hovorů Počet souběžných hovorů Celková šířka pásma
Aplikace Webex/Stolní telefon → Aplikace Webex 15 2 * 15 * 70 kb/s = 2 100 kb/s
Aplikace Webex/Stolní telefon → Stolní telefon 15 2 * 15 * 70 kb/s = 2 100 kb/s
Aplikace Webex/Stolní telefon → PSTN přes LGW 50 2 * 50 * 80 kb/s = 8 000 kb/s
Aplikace Webex/Stolní telefon → PSTN přes Cloud Connect pro Webex Calling 0 0* 80 kb/s
Aplikace Webex/Stolní telefon → Enterprise přes LGW 15 2 * 15 * 80 kb/s = 2400 kb/s
Aplikace Webex/Stolní telefon → Webex Calling Hlasová schránka 5 5 * 70 kb/s = 350 kb/s
Celkový počet hovorů/šířka pásma 100 hovorů 14 950 kb/s/14,95 Mb/s

Všechny hodnoty šířky pásma ve výše uvedených tabulkách odkazují na šířku pásma IP. Šířka pásma linky je vyšší v závislosti na zapouzdření WAN.

Šířka pásma ve výše uvedených tabulkách je pro zvuk ové hovory. Pokud jde o šířku pásma videohovorů, aplikace Webex a telefony MPP 8845/65 podporují video H.264 s maximálním rozlišením 720p při maximální šířce pásma 1 500 kb/s na hovor. Množství šířky pásma spotřebované v kterémkoli bodě během hovoru však bude kolísat na základě proměnné přenosové rychlosti vlastní video komunikaci.

Kvalita služeb (QoS)

Implementujte zásady QoS v místním prostředí, abyste upřednostnili provoz v reálném čase a zajistili udržování QoS napříč přepínači, směrovači a firewally.

Cíle latence, chvění a ztráty paketů

Následující prahové hodnoty se doporučují pro optimální kvalitu hlasu při volání přes internet (Over-the-Top) (OTT):

Latence - méně než 100 ms jednosměrná

Jitter - méně než 10 ms

Ztráta paketů - 0,5% nebo méně.

Firewall a NAT

Zkontrolujte, zda je brána firewall nakonfigurována tak, aby umožňovala provoz, jak je uvedeno v článku dostupném na stránce Referenční informace o portu pro Webex Calling. Dále povolte přístup k doménám a rozsahům IP uvedeným ve stejném průvodci a vyhněte se SIP ALG, protože narušuje signalizaci SIP. Je třeba se vyhnout mediálnímu provozu prostřednictvím proxy serverů.

DNS a NTP

Zajistěte správné rozlišení DNS domén a spolehlivé servery NTP pro synchronizaci hodin zařízení pro ověření a protokolování certifikátů TLS.

Plánování převzetí služeb při selhání

Zvažte stávající datová připojení poskytovatele (MPLS, SD-WAN atd.) a obecně plánujte přímý přístup k internetu na každém místě v rámci nas azení. Plánujte redundantní internet ové připojení tam, kde je vyžadována vysoká dostupnost. Protože budete spotřebo vávat cloudové služby, je základním požadavkem spolehlivé připojení k internetu s dostatečnou šířkou pásma. Tento přechod byste měli přehodnotit, pokud připojení k internetu v lokalitách vaší organizace není obecně spolehlivé s nízkou latencí a dostatečnou propustností pro vyšší a následnou propustnost.

Odolnost webu

Odolnost webu zajišťuje, že vaše podnikání je vždy dosažit elné, i když se vaše síťové připojení přeruší. Site Survivalability používá bránu ve vaší místní síti k poskytování služby záložního volání koncovým bodům na místě v situacích, kdy dojde k přerušení síťového připojení. Pokud obchodní požadavky vyžadují nepřetržité volání v případě vý padku sítě, zvažte přežití webu s místní bránou Survivalability Gateway (SGW). Další informace o kontrole přežití webu, viz Pře žití webu pro. Webex Calling

Nastavení cloudové komunikace propojené

Cloud Connected UC (CCUC) je cloudové řešení pro správu a analýzu navržené tak, aby poskytovalo centralizovanou viditelnost, správu a přehledy pro místní nasazení (například) i cloud (Unified CM). Funguje jako most mezi tradičními místními prostředími a clou dovými službami společnosti Cisco a podporuje organizace na cestě migrace z do.

Během přechodu na, CCUC hraje zásadní roli při zefektivnění procesu migrace usnadněním shromažďování komplexních dat ze stávajícího nasazení Unified Communications. CCUC pomáhá s klíčovými úkoly přechodu, jako je migrace zařízení, funkcí a kontaktů uživatelů, stejně jako automatizace aktualizací firmwaru pro podporované IP telefony. Díky centralizovanému přehledu a správě pomáhá CCUC zajistit plynulejší a efektivnější migraci.

Společnost Cisco důrazně doporučuje, aby byl CCUC nasazen a nasazen brzy v přechodovém projektu, nejlépe před nebo během fáze přípravy. To umožní přehled a schopnosti potřebné k důkladnému vyhodnocení, inventarizaci a plánování následných migračních aktivit a zahájení vaší cesty k budoucím hybridním schopnostem.

Posouzení současného prostředí

Klíčovou činností při plánování migrace je posouzení aktuálního místního prostředí a nasazení. To poskytuje přehled o tom, na jaké potenciální změny mohou být nutné k úspěšnému přechodu. Umožňuje také posoudit klíčové prvky platformy ve srovnání se stávajícím místním nasazením. Pomocí těchto informací můžete určit, jaké konkrétní úkoly jsou pro přechod vyžadovány a jaké změny chcete provést, abyste splnili své obchodní a technické požadavky a případy použití.

V rámci tohoto úsilí je důležité přezkoumat následující aspekty.

Licencování

Pochopení aktuální struktury licencí stávajícího nasazení je klíčové při přípravě na migraci na. Proveďte posouzení licencí následujících oblastí vašeho stávajícího místního řešení Cisco.

Nástupiště

Schopnost plně formulovat, co je aktuálně licencováno na vaší základní platformě, bude rozhodující při spolupráci s vaším týmem účtu nebo partnerem na určení nejlepší cesty k flexibilní licencování . je licencován pomocí flex licencování. Další informace o flexibilním licencování naleznete v tématu Cisco Collaboration flex plan.

Uživatelé a zařízení

Určete, jakou kategorii licencí vaši stávající uživatelé a zařízení vyžadují. To bude použito k určení, jaký typ licence je vyžadován pro uživatele a zařízení. nabízí několik typů licencí, včetně licencí Professional a Standard pro uživatele a licencí Professional a common area pro pracovní prostory. Další informace o licencování zařízení naleznete v datovém listu dostupném na stránce Licencování zařízení.

Místní brána

Pokud je Cisco Unified Border Element (CUBE) vyžadován pro přístup PSTN pro tento přechod, je třeba zvážit také licencování CUBE. Úvahy o licencování CU BE jsou popsány dále v tomto dokumentu.

Místa/Stránky

Při plánování tohoto přechodu je třeba vzít v úvahu počet a typy lokalit (velké centrální, regionální, pobočkové atd.) v rámci stávajícího nasazení. Plné poroz umění stávajícím lokalitám nasazení pomůže při strategickém plánování úspěšného přechodu, zejména pokud jde o určení, které lokality migrovat a v jakém pořadí. Při rozhodování o migraci bude rozhodující porozumět podrobným požadavkům na vytáčecí plán (číslování, návyky vytáčení, třídy omezení atd.), připojení k síti webu a šířku pásma (internet, WAN, LAN) a přístupu PSTN (místní nebo centralizovaný, IP nebo TDM) pro každý web. Další informace o běžných modelech nasazení a klíčových aspektech naleznete v informacích o modelech nasazení spolupráce, které jsou k dispozici v dokumentu SRND spolupráce.

Dalším důležitým aspektem nasazení při přechodu na umístění je dostupnost umístění. má různé funkce, předplatné a zařízení, která jsou k dispozici v závislosti na umístění vašeho nasazení. Další informace o geografické dostupnosti naleznete v části Kde je Webex k dispozici? .

Nakonec je důležité pochopit dopad, který bude mít přechod na další služby spolupráce. Na základě cíle tohoto dokumentu je obecným předpokladem, že pokud mají být zacho vány stávající služby spolupráce mimo pracovní zátěž volání, očekává se přechod na výše uvedené hybridní nasazení fáze 1. Mezi příklady služeb spolupráce, které mohou vyžadovat hybridní nasazení, patří místní kontaktní centrum, které ještě nebylo migrováno do kontaktního centra Webex, a těsné integrace do systémů, jako jsou stránkovací systémy a fakturace. Další informace o přechodu dalších úloh spolupráce a služeb naleznete v tématu Přec hody spolupráce.

Inventarizace stávajících zařízení/klientů

Před zahájením přechodu je důležité inventarizovat stávající hardwarové a softwarové koncové body. Úplný seznam typů/modelů zařízení, verzí hardwaru, typů softwarových klientských operačních systémů a množství zajistí, že budete moci adekvátně naplánovat přecho d zařízení a zmírnit dopad na zařízení, která nelze migrovat na cloudové volání. Inventář by měl být použit k určení zařízení k přechodu a zařízení, která mají být vyměněna před přechodem.

Stolní telefony

Pro audio a video stolní telefony jsou podporovány pouze stolní telefony řady 6800,7800,8800 a 9800. Toto je podmnožina telefonů Cisco IP, které jsou podporovány. Existují některé modely a verze telefonů 6800,7800 a 8800, se kterými nelze použít. Další informace o podporovaných modelech a verzích hardwaru naleznete v části Pod porovaná zařízení pro Webex Calling.

IP telefony řady Cisco 6800 nelze upgradovat z podnikového firmwaru na multiplatformní (MPP) firmware, který je vyžadován pro. Proto musí být všechny telefony 6800 registrované pro běžící firemní firmware nahrazeny modelem 6800 MPP nebo jiným podporovaným modelem telefonu.

IP telefony řady Cisco 7800 a 8800 musí být před přechodem a registrací upgradovány na firmware Multiplatform Phone (MPP). Chcete-li zjistit, které modely 7800 a 8800 a verze hardwaru podporují firmware MPP, přečtěte si článek Převod IP telefonů Cisco řady 7800 a 8800 mezi firmwarem Enterprise a MPP.

Modely 8845,8865 a 8865NR dosáhly konce prodeje a nedoporučuje se na ně migrovat.

Starší verze telefonů řady 8800 (8811,8841,8851, 8851NR, 8861) se nedoporučují používat. Webex Calling Telefony s hardwarovou verzí VID 14 nebo starší se zaregistrují, ale mohou se vyskytnout některé problémy s výkonem kvůli hardwaru.

Stolní telefony řady 9800 běží na PhoneOS, který podporuje jak registraci, tak i registraci. Proto lze tyto telefony přepnout bez upgradu firmwaru.

Všechny ostatní IP telefony budou muset být nahrazeny telefony řady 6800,7800,8800 nebo 9800 podporovanými. Webex Calling Další informace o podporovaných telefonech IP a stolních telefonech naleznete v článku Podporovaná zařízení pro Webex Calling.

Koncové body videa

Koncové body pro osobní a pokojové video, včetně řady Cisco Board, řady Room a Desk, lze nati vně zaregistrovat do protokolu SIP. Kterýkoli z těchto koncových bodů, které potřebují uskutečňovat zvukové hovory a/nebo volání PSTN, vyžaduje volací licenci:

Sdílená zařízení v konferenčních místnostech, společenských prostorách atd. vyžadují licenci Professional Workspace nebo Workspace.

Osobní zařízení koncového uživatele vyžaduje profesionální nebo standardní licenci.

Určete, kolik koncových bodů videa je registrováno a kolik se používá k uskutečňování zvukových hovorů. Je možné, že některé koncové body videa mohou být použity pouze pro připojení ke schůzkám nebo pro videohovory SIP. V obou případech je ještě potřeba migrovat koncové body, než budou servery vyřazeny z provozu, nicméně to pomůže určit, kolik z nich bude potřebovat licence k dalšímu telefonování.

Když jsou video zařízení přesunuta z registrace do, URI pro tyto koncové body se změní, protože jsou nyní registrovány v cloudu.

Modely telefonů 8845,8865 a 8875 jsou osobní video telefony, které jsou podporovány.

Měkké klienty

Je jediným softwarovým klientem podporovaným, na rozdíl od Unified CM kterého podporuje aplikaci Webex i Jabber, a je novým výchozím softwarovým klientem pro koncové uživatele.

V závislosti na režimech nasazení implementovaných pro Jabber (režimy pouze IM, pouze telefon a/nebo plné UC) možná budete muset zvážit také přechod úloh Zprávy a/nebo Meetings z Jabber na. Může být nasazen pouze v telefonickém režimu, pokud bude použit jako klient pouze pro volání, nebo může být nasazen jako pl nohodnotný v Webex Suite případě jiných úloh, např. Webex Messaginga/nebo Webex Meetings jsou přecházeny do aplikace s voláním.

Vylepšuje zážitek koncového uživatele poskytováním funkcí AI, jako je audio/video inteligence, přepis hovorů a další. Další informace naleznete na adrese https://www.webex.com/all-new-webex.

Před přesunem uživatelů na něj budete muset převést jejich klienty Jabber na. K dokončení tohoto přechodu máte dvě možnosti.

Než je převedete na

Když je převedete na.

Pro usnadnění počátečního přechodu na, doporučuje se použít možnost 1 a přesunout uživatele nejprve na voláním. To dává uživatelům čas na seznámení se s novou aplikací, zatímco stále používají stávající místní volací platformu. Jakmile budete připraveni přesunout uživatele, nakonfigurujete je tak, aby se zaregistrovali na platformě cloudových volání.

Další informace o těchto dvou možnostech najdete v tématu C esta migrace - jeden nebo dva kroky? .

Úplný seznam podporovaných zařízení pro, viz Podporovaná zařízení pro Webex Calling.

Ověřte způsobilost zařízení

Jak již bylo zmíněno dříve, podporuje podmnožinu telefonů Cisco IP a vyžaduje jiný typ firmwaru pro telefony řady 7800 a 8800. Unified CMtelefony používají firmware Enterprise, zatímco telefony spouštějí firmware Multiplatform Phone (MPP). Doporučuje se ověřit, které registrované telefony jsou způsobilé k upgradu na firmware MPP během fáze Prepare. To vám dává čas na nahrazení nezpůsobilých telefonů jedním z podporovaných modelů telefonů nebo na identifikaci alternativního plánu, jako je přesun uživatele pouze do aplikace Webex.

Pro určení způsobilosti telefonů má Control Hub vestavěný nástroj s názvem Migrace telefonu do Webex Calling. Pokud používáte tento nástroj ke kontrole způsobilosti zařízení, vyberte možnost Migrace Generovat pouze licenci zařízení.

Možnost nástroje Control Hub k ověření způsobilosti Unified CM telefonů pro Webex Calling

Tato možnost umožňuje nahrát soubor CSV obsahující telefony, takže můžete zkontrolovat způsobilost každého telefonu. Výběrem této možnosti migrace ne přidá telefony, protože jste stále ve fázi přípravy a ještě nejste připraveni to udělat. Další informace naleznete v tématu Migrace telefonu do Webex Calling.

Je možné, že některé telefony se mohou vrátit s nezná mou způsobilostí. Je to obvykle proto, že není schopen ověřit některé informace o telefonu v back-endovém systému. U všech telefonů, které mají stav Nezná mý, máte dvě možnosti, jak ověřit, zda mají nárok na upgrade na firmware MPP.

Ručně zkontrolujte každý telefon a ověřte model a verzi hardwaru (PID VID)

7800/8800 telefonní štítek s informacemi o modelu a verzi hardwaru

Použijte nástroj připravenosti telefonů Cisco IP

Stáhněte si nástroj z https://github.com/joemar2/mpp_readiness_check.

Tento nástroj není oficiálním nástrojem Cisco ani není podporován TAC. Má maximální podporu, ale je zdarma k použití.

Tento nástroj musí být spuštěn na místním počítači, který má přístup k serverům a telefonům IP. Má možnost povolit přístup na web na IP telefonech, což je doporučeno a potřebné k dosažení nejlepších výsledků. Proto by měl být používán mimo pracovní dobu, aby nedošlo k narušení koncových uživatelů. Výstup nástroje poskytuje zprávu se seznamem telefonů řady 7800 a 8800, které jsou způsobilé pro upgrade na firmware MPP. Protože přímo přistupuje k telefonu, může ověřit nezná má zařízení, která byla nahlášena z nástroje Control Hub.

Zpráva o nástroji připravenosti telefonů Cisco IP

Uživatelé

Jedním z nejdůležitějších přípravných kroků k zajištění úspěšné migrace je správné zřizování uživatelů. Musíte správně naplánovat pro všechny uživatele, i když provádíte postupnou migraci. Uživatelé musí být zřízeni pro některou z následujících možností:

Nasazení s voláním

Nasazení s

Konfigurace služeb pro uživatele

Umožnit vyhledávání uživatelů v adresáři (click-to-call, User contact info, search telefonního adresáře).

Doporučuje se zřídit všechny uživatele před nebo na začátku projektu. To zahrnuje uživatele, kteří stále používají Unified CM pro svou volací platformu nezávislou na svém volajícím zařízení (IP telefon, Jabber,). Jakmile budou uživatelé migrováni na (a/nebo na), aktualizujete jejich licence, abyste povolili služby, které potřebují. Zřízení všech podnikových volajících uživatelů před zahájením přechodu umožňuje uživateli, který přešel do nebo, vyhledat v adresáři podnikového volajícího uživatele, který je stále na Jabberu a/nebo zapnutém. Tím je zajištěno, že přechodovaní uživatelé mohou najít kontaktní informace jakéhokoli jiného uživatele a zavolat jim pomocí vyhledávání adresáře.

Vyhledávání v adres áři obrázků ukazuje příklad uživatele, který hledá jiného uživatele. Výsledky vyhledávání zobrazují kontaktní informace uživatele a mohou být pro uživatele, který je stále na Jabberu, nebo pro uživatele, který přešel na a/nebo.

Vyhledávání v adresáři aplikace Webex

Dále určete, na kterého ze stávajících místních volajících uživatelů bude přechod. Pokud dojde k přechodu všech nebo velkého počtu uživatelů, doporučuje se přesunout uživatele do skupin, aby bylo zajištěno, že projektový tým, pracovníci IT a pracovníci podpory budou schopni zvlád nout přechod a případné problémy, které mohou nastat. Měli byste také vyčlenit nějaký čas na poskyt nutí počátečních informací a školení k přípravě uživatelů na tento přechod. Seskupování přechodu uživatelů lze provádět na základě různých kritérií, včetně umístění nebo webu, ke kterému jsou uživatelé přiřazeni, oddělení uživatelů nebo dokonce typy uživatelů (znalostní pracovníci, vedoucí pracovníci, mobilní pracovníci atd.).

Pokud jsou například uživatelé v nasazení rozděleni na tři hlavní lokality, New York (NYC), San Francisco (SFC) a Research Triangle Park (RTP), plán přechodu uživatelů může vypadat jako plán uvedený v tabulce přechodu uživatele podle tabulky.
Tabulka 4. Plán přechodu uživatele podle webu
Uživatelská stránka/ umístění Informace před přechodem a školení Přechodné období Podpora po přechodu
NYC (1 525 uživatelů) Týden 1. dubna 15. dubna — 27. dubna Týden od 29. dubna
SFO (1 600 uživatelů) Týden od 6. května 20. května — 31. května Týden 3. června
RTP (1 275 uživatelů) Týden 3. června 17. června — 28. června Týden 1. července

Dalším důležitým faktorem je přechod uživatelů, kteří mají mezi sebou závislosti. To může zahrnovat, ale není omezeno na následující:

Monitorování BLF

Stejný lovecký pilot/skupina

Sdílet řádky

Část stejné skupiny pro vyzvednutí hovorů

Používání stejných čísel parkovacích míst

Interkom

Admin/Exec.

Konfiguraci můžete zkontrolovat (grafické rozhraní nebo export) nebo pomocí nástroje Migration Insights identifikovat skupiny uživatelů s těmito závislostmi.

Připojení PSTN

může přistupovat k PSTN třemi způsoby: plány volání Cisco, Cloud connect for (dříve Cloud Connected PSTN) a místní PSTN (místní brána). Jedno umístění, jak je definováno v rámci možnosti PSTN, však lze přiřadit pouze jedné možnosti PSTN.

Místní síť PSTN s lokální bránou (LGW) je nezbytnou součástí strategie přechodu. Poskytuje konektivitu mezi místním nasazením a/nebo PSTN a platformou. podporuje jak Cisco, tak certifikované hraniční řadiče relací (SBC) třetích stran, které lze použít jako místní bránu. Nejnovější seznam podporovaných SBC najdete v části Seznam podporovaných SB C.

podporuje až 250 souběžných hovorů z jedné místní brány založené na registraci a více než 250 souběžných volání z jedné místní brány založené na certifikátu. Místní brány založené na certifikátech mohou podporovat až 6500 souběžných hovorů, ale to je založeno na typu připojení, které musí místní brána (Over-the-Top vs. interconnect peering) a modelu SBC, na kterém je místní brána nasazena. Tyto limity jsou v podstatě výchozím limitem počtu jak pro volání PSTN založené na místní bráně, tak pro volání mezi lokalitami a koncovými body. Další informace naleznete v tématu Začínáme s místní bránou.

Jakékoli hovory překračující tento limit jsou odmítnuty s 403 Forbidden. Hlasový příkaz Zobrazit aktivní volání lze spustit na místní bráně v libovolné instanci, aby se urč il celkový počet aktivních hovorů.

Špatné síťové podmínky mezi místní bránou a přístupovým SBC mohou omezit výkon signalizačního spojení, což vede k ještě nižšímu limitu sou běžných hovorů. Jednosměrná latence mezi lokální bránou a datovým centrem by neměla přesáhnout 100 ms a chvění by mělo být menší než 10 ms, zatímco ztráta paketů je menší než 0,5%.

Funkce a využití funkcí

Při posuzování aktuálního prostředí je důležité identifikovat a zkontrolovat, které funkce jsou nakonfigurovány. Kromě toho je důležité porozumět využití funkcí, abyste mohli (znovu) definovat své obchodní a technické požadavky pro vaše nasazení.

Chcete-li zjistit, které funkce jsou nakonfigurovány, analyzujte konfiguraci. Jedná se o všechna statická data, která jsou nastavena, když je v systému nakonfiguro vána funkce nebo nastavení. K dokončení této analýzy lze použít následující možnosti:

Zkontrolujte konfiguraci v administrátorském GUI

export konfigurace - hromadný export nebo AXL

nástroj pro přehledy migrace (doporučeno)

Nástroje pro partnery třetích stran Cisco (doporučeno).

Pro efektivní analýzu využití funkcí je nezbytné prozkoumat dynamická systémová data, jako je využití, registrace a aktivita hovorů. Různé analytické nástroje a řídicí panely poskytují přehled o těchto metrikách a umožňují komplexní pochopení výkonu a kapacity systému, což podporuje informované rozhodování během migrace a optimalizace. K dokončení tohoto typu analýzy lze použít následující možnosti:

Přehled nezpracovaných záznamů CDR

Přehled údajů Unified CM RTMT

Nástroj Migration Insights využívající data CDR

Recenze analytiky UC připojených k cloudu v

Hlasitost hovoru

Registrované koncové body

(CAC) lokality

Využití kufru.

Nástroje pro partnery třetích stran Cisco.

Společnost Cisco doporučuje začít s nástrojem Webex Control Hub Migration Insights pro tuto analýzu. Importujete exportní soubor.TAR a soubory Unified CM CDR (volitelné, ale nutné pro analýzu využití prvků) do nástroje. Nástroj vygeneruje následující zprávy založené na CSV , které lze použít k zahájení analýzy:

Tabulka 5. Zprávy generované ze Unified CM souboru.tar
Název zprávy
Popis zprávy
ImportedDataBulk.csv
Všichni uživatelé a zařízení z Unified CM dat
DeviceEligibility.csv
Identifikuje zařízení způsobilá k migraci Webex Calling (IP telefony, zařízení Room OS, ATA a třetí strany)
DevicePoolNumbers.txt
Seznam všech čísel v určitém fondu zařízení
HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv
Podrobnosti o zařízeních a uživatelích, které by měly být migrovány společně na základě sdílených linek, loveckého pilota, fronty hovorů, parkování hovorů a konfigurace skupiny pro vyzvednutí hovorů
HuntGroupMigrationInsight.csv
Podrobné informace o přiřazených lovec kých liniích, skupinách čar a přidružených agentech
SharedlineGroupMigrationReport.csv
Přehled sdílení telefonních čísel (adresářových čísel) mezi uživateli

Tabulka 6. Zprávy generované ze soubor Unified CM ů.tar a CDR. gzip
Název zprávy
Popis zprávy
FeatureUsageBasedDeviceEligibilityReport.csv
Informace o způsobilosti pro migraci zařízení na základě využití funkce
FeatureUsageWithLastUsageDateReport.csv
Počet využití pro počet volaných pilotů a fronty volání spolu s datem posledního použití
UserWorkspaceLastUsage.csv
Datum posledního použití pro uživatele a pracovní prostory pro softwarové klienty i pevné telefony
DIDUsageReport.csv
Využití DID pro přiřazené i nepřiřazené DID

Další podrobnosti o přehledech Migration Insights najdete v tématu Přehled migrace .

Pokud potřebujete další informace o funkcích a využití po přečtení informací v přehledech Migration Insights, společnost Cisco doporučuje zvážit jeden z nástrojů pro migraci partnerů třetích stran společnosti Cisco a/nebo zkontrolovat konfigurace v grafickém rozhraní nebo v datech exportu konfigurací.

Integrace společnosti Cisco: Unity Connection UCCX UCCE

Hlasová schránka je nedílnou součástí nabídky a nativně zabudovaná do řešení. nelze integrovat s místním řešením hlasové schránky, jako je Unity Connection nebo Unity Connection Express. Dále, neexistuje žádný nativní způsob, jak migrovat stávající hlasové zprávy nebo pozdravy připojení Unity na nativní službu hlasové schránky dostupné u. Některé nástroje pro migraci partnerů třetích stran společnosti Cisco mají možnosti migr ace některých těchto dat. Další informace o hlasové schránce pro, viz Konfigurace a správa nastavení hlasové schránky pro uživatele. Webex Calling

podporuje také sdílené hlasové schránky a faxové poštovní schránky. Další informace naleznete v tématu Správa sdílené hlasové schránky a příchozí faxové schránky pro. Webex Calling

má vestavěnou funkci Auto Attendant, která je součástí základní platformy. Tato funkce umožňuje přechod obsluhy hovorů vašeho Unity Connection a funkce automatické obsluhy . Nástroj Řídicího centra Migrace funkcí z Unified CM podporuje migraci konfigurací připojení Unity na automatické obsluhy. Další informace o používání tohoto nástroje naleznete v tématu Migrace zařízení a funkcí z Unified CM doWebex Calling.

Nahrávání hovorů

obsahuje dvě možnosti pro nahrávání hovorů bez dalších nákladů.

Nahrávání hovorů Webex

Dubber Go nahrávání (nabídka partnera) - integrace mezi a dubber, kde jsou všechna nahraná média bezpečně uložena v cloudu.

zahrnutá tabulka možností nahrávání zdůrazňuje některé klíčové funkce dvou možností nahrávání hovorů, které jsou k dispozici bez dalších nákladů.

Tabulka 7. zahrnuté možnosti nahrávání
Webex Double Go

Dostupné všem uživatelům Dostupné všem uživatelům

Neomezené nahrávky Neomezené nahrávky

Doba uchovávání 1 roč* 30denní retenční doba

100 GB úložiště na organizaci -

Pracovníci pro dodržování předpisů mohou přistupovat k záznamům hovorů a spravovat je -

API pro správu nahrávek -

Správci mohou konfigurovat a spravovat přístup uživatelů k nahrávkám hovorů
Uživatelé mohou spravovat své vlastní nahrávky pomocí User Hub a/nebo aplikace Webex.
Pouze uživatelé mohou přistupovat a spravovat své nahrávky
Z jejich dubberového portálu.

Pokud vaše organizace vyžaduje další možnosti nahrávání, jako je nahrávání hovorů v souladu s předpisy, delší doby uchovávání, větší úložiště, analýza umělé inteligence a/nebo přístup správce, existují placené nabídky nebo doplňky od Cisco i poskytovatelů nahrávání třetích stran. Další informace o poskytovatelích nahrávání, konfiguracích a doplňkových partnerských službách naleznete v tématu S práva nahrávání hovorů pro Webex Calling.

Integrace třetích stran

podporuje celou řadu integrací třetích ^stran, mimo jiné včetně SBC pro místní brány, IP telefony, interkomové telefony, reproduktory/pagery, ATA atd. Kromě těchto zařízení třetích stran ^{Webex Callingpodporuje} různá řešení třetích stran ^pro zákaznickou podporu, analýzu, nahrávání, fakturaci atd. Další informace o řešen ích ^třetích stran naleznete v tématu Webex App Hub.

Tabulka 4. Plán přechodu uživatele podle webu
Uživatelská stránka/ umístění	Informace před přechodem a školení	Přechodné období	Podpora po přechodu
NYC (1 525 uživatelů)	Týden 1. dubna	15. dubna — 27. dubna	Týden od 29. dubna
SFO (1 600 uživatelů)	Týden od 6. května	20. května — 31. května	Týden 3. června
RTP (1 275 uživatelů)	Týden 3. června	17. června — 28. června	Týden 1. července

Tabulka 5. Zprávy generované ze Unified CM souboru.tar
Název zprávy Popis zprávy
ImportedDataBulk.csv Všichni uživatelé a zařízení z Unified CM dat
DeviceEligibility.csv Identifikuje zařízení způsobilá k migraci Webex Calling (IP telefony, zařízení Room OS, ATA a třetí strany)
DevicePoolNumbers.txt Seznam všech čísel v určitém fondu zařízení
HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv Podrobnosti o zařízeních a uživatelích, které by měly být migrovány společně na základě sdílených linek, loveckého pilota, fronty hovorů, parkování hovorů a konfigurace skupiny pro vyzvednutí hovorů
HuntGroupMigrationInsight.csv Podrobné informace o přiřazených lovec kých liniích, skupinách čar a přidružených agentech
SharedlineGroupMigrationReport.csv Přehled sdílení telefonních čísel (adresářových čísel) mezi uživateli

Tabulka 6. Zprávy generované ze soubor Unified CM ů.tar a CDR. gzip
Název zprávy Popis zprávy
FeatureUsageBasedDeviceEligibilityReport.csv Informace o způsobilosti pro migraci zařízení na základě využití funkce
FeatureUsageWithLastUsageDateReport.csv Počet využití pro počet volaných pilotů a fronty volání spolu s datem posledního použití
UserWorkspaceLastUsage.csv Datum posledního použití pro uživatele a pracovní prostory pro softwarové klienty i pevné telefony
DIDUsageReport.csv Využití DID pro přiřazené i nepřiřazené DID

Tabulka 7. zahrnuté možnosti nahrávání
Webex	Double Go
Dostupné všem uživatelům	Dostupné všem uživatelům
Neomezené nahrávky	Neomezené nahrávky
Doba uchovávání 1 roč*	30denní retenční doba
100 GB úložiště na organizaci	-
Pracovníci pro dodržování předpisů mohou přistupovat k záznamům hovorů a spravovat je	-
API pro správu nahrávek	-
Správci mohou konfigurovat a spravovat přístup uživatelů k nahrávkám hovorů Uživatelé mohou spravovat své vlastní nahrávky pomocí User Hub a/nebo aplikace Webex.	Pouze uživatelé mohou přistupovat a spravovat své nahrávky Z jejich dubberového portálu.

Plán

Plán projektu na vysoké úrovni

Migrační cesta - jeden nebo dva kroky?

Možnost 1: Jednostupňová migrace uživatele

Možnost 2: Migrace uživatele ve dvou krocích

Krok 1

Krok 2

Plán projektu na vysoké úrovni

Při vytváření plánu projektu na vysoké úrovni pro migraci z do, je nezbytné stanovit jasné fáze a milníky, které jsou v souladu s obchodními cíli i technickými požadavky. Plán by měl začít komplexní fází hodnocení, včetně shromažďování podrobných technických a obchodních požadavků, jakož i identifikace zúčastněných stran a definování kritérií úspěchu. Mezi klíčové aspekty patří alokace zdrojů, odhad časové osy, řízení rizik a komunikační strategie, které zajistí, že všechny strany budou během migrace informovány a zapojeny. Plán by navíc měl zahrnovat kontrolní body ověření, jako je pilotní testování a postupné zavádění, aby se minimalizovalo narušení a umožnilo úpravy na základě zpětné vazby.

Příklady prvků, které mají být zahrnuty do plánu projektu, jsou:

Definování rozsahu migrace (např. ke kterým uživatelům, zařízením a funkcím dojde k přechodu)

Plánování školení pro koncové uživatele a týmy podpory

koordinace hodnocení připravenosti sítě a

Plánování aktivit s možností nouze. Je také důležité integrovat kontroly dodržování předpisů a zabezpečení, jakož i fáze podpory a optimalizace po migraci.

Strukturováním plánu projektu s těmito úvahami mohou organizace lépe řídit složitost, snižovat rizika a dosáhnout plynulejšího přechodu na.

Migrační cesta - jeden nebo dva kroky?

vyžaduje, aby uživatelé používali pro volání měkkého klienta. Proto, pokud někteří uživatelé stále používají, máte dvě možnosti, kdy je můžete přesunout do. Můžete provést migraci uživatele v jednom kroku nebo migraci uživatele ve dvou krocích.

Možnost 1: Jednostupňová migrace uživatele

V jednom kroku migrace, uživatelé přecházejí z do současně s přechodem z Unified CM do. Tato možnost je obvykle určena zákazníkům s malým počtem uživatelů k migraci a mohou spravovat přesun softwarového klienta uživatele i služby volání současně. Obrázek, na který migruje současně služba volání uživatele, softwarový klient a telefon níže, zdůrazňuje tento typ migrace. S touto volbou bude uživatel mít dokončeno následující současně:

Volací služby byly přesunuty z do

Telefonní čísla a rozšíření přesunuty z do

Softwarový klient přešel z Jabberu na - zaregistruje se do

Registrace telefonu se přesunula z do.

Služba volání uživatele, softwarový klient a telefon migrují současně

Stále se může jednat o postupnou migraci, kdy se skupiny uživatelů přesouvají v různých časech, ale když je každý uživatel přesunut, všechny tyto změny probíhají současně.

Možnost 2: Migrace uživatele ve dvou krocích

Druhým přístupem je migrace ve dvou krocích. V kroku 1, uživatelé jsou převedeni z na služby, ale zůstávají zapnuti pro volání. Poté v kroku 2, uživatelé jsou přesunuti z Unified CM do. Tato možnost se doporučuje větším zákazníkům, kteří spravují změny koncového uživatele a chtějí oddělit změnu měkkého klienta uživatele od změny služby volání. Následující obrázek Migrace měkkého klienta; poté migrujte službu volání, softwarového klienta a telefonu Webex Calling níže zvýrazňuje tento typ migrace.

Krok 1

Měkký klient přešel z na - zaregistruje se do.

Krok 2

Volací služby se přesunuly z do.

Telefonní čísla a rozšíření přesunuty z do.

registrace přesunuta z do.

Registrace telefonu se přesunula z do.

Migrujte softwarového klienta; poté migrujte volací službu, softwarového klienta a telefon na Webex Calling

Stále se může jednat o postupnou migraci, kdy se skupiny uživatelů přesouvají v různých časech v obou krocích.

Volba, kterou vyberete, závisí na tom, jak chcete spravovat přechod uživatelů na a. Doporučuje se postupovat v krocích (možnost 2). To vám umožní minimalizovat změny koncového uživatele najednou a rozdělit úsilí mezi různé části projektu. Pokud však dáváte přednost tomu, aby uživatelé byli ovlivněni pouze jednou, pak je použití možnosti 1 také platné.

Když se podíváme na doporučenou cestu (možnost 1), obrázek mapy přechodu na vysoké úrovni aplikace Jabber na Webex níže ukazuje přecho d na vysoké úrovni pro krok 1.

Mapa přechodu na vysoké úrovni aplikace Jabber na Webex

V tomto kroku jsou uživatelé převedeni z Jabberu na všechny své volací služby. nicméně, volající platforma je stále Unified CM a bude registrovat své volací služby. Jak je vidět na obrázku přechodu na vysoké úrovni aplikace Jabber na Webex, místní infrastruktura se nemění a funguje stejně jako Jabber. Jedinou změnou je, že vyžaduje připojení.

Další informace o tomto přechodu naleznete v tématu Průvodce mapou přechodu a nasazením Jabber na Webex v části Klient na stránce Přecho d spolupráce.

Unified CMWebex Callingna obrázek přechodové mapy na vysoké úrovni je přechod na vysoké úrovni z na. Toto je krok 2 doporučené cesty.

Unified CMna mapu přecho Webex Calling du na vysoké úrovni

Pokud se rozhodnete použít jednokrokový přístup, platí to také.

V tomto kroku jsou uživatelé přecházeni ve skupinách. V tomto okamžiku uživatelé začnou používat pro své volací služby, registraci volání a registraci IP telefonu.

Protože se uživatelé pohybují ve skupinách, Enterprise uživatelé budou během přechodu rozděleni mezi dvě volající platformy. Fáze 1 Unified CMna obrázku přecho Webex Calling dové mapy na vysoké úrovni zobrazuje tento stav. Během této fáze je nutné plánování, jak spravovat hovory mezi uživateli na obou platformách a jak budou směrovány hovory PSTN. Pokaždé, když dojde k přechodu na skupinu uživatelů, budou vyžadovány aktualizace telefonického tarifu a směrování hovorů a místní brány.

Po přechodu na všechny uživatele, softwarové klienty a zařízení (fáze 2) lze veškerou místní infrastrukturu UC odebrat a vyřadit z provozu.

Návrh

Výběr regionu

Lokality

PSTN

Číselný plán

Místní vytáčecí plán v

číselný plán

Nahrávání

1. Výběr poskytovatele nahrávání hovorů

2. Výběr regionu

Tísňové volání

Licencování

Ruční přiřazení přes

Šablony automatického přiřazení licencí

Hromadné přiřazení prostřednictvím šablony CSV

Přiřazení na základě rozhraní API

Požadavky na licenci

Zřizování uživatelů

Skupiny uživatelů

Doporučený přístup při migraci z do

Navrhování skupin uživatelů

Jednotné přihlášení (SSO)

Podpora více IdP

1. Fúze a akvizice

2. Více nezávislých IT oddělení

3. Různé skupiny uživatelů nebo domény

4. Podpora různých autentizačních protokolů

5. Vylepšené zabezpečení a dodržování předpisů

6. Zjednodušené uživatelské prostředí

Duo MFA s SSO pro

Vlastnosti

Automatická obsluha

Volejte Park

Vyzvednutí hovorů

Fronta hovorů

Huntská skupina

Provozní režimy

Skupina stránkování

nahrávky

Dosah jednoho čísla

Skupina hlasové schránky

Výběr regionu

je dostupný po celém světě a je dodáván z redundantních datových center ve více regionech: USA (Dallas, Chicago), Kanada (Vancouver, Toronto), Evropa (Frankfurt, Amsterdam), Velká Británie (Londýn, Manchester), Austrálie (Melbourne, Sydney), Japonsko (Tokio, Osaka), Saúdská Arábie (Rijád, Džidda) a Indie (Bombaj, Chennai). Mediální POP poskytují mediální služby pro optimalizaci doby zpá teční cesty médií. Singapurské datové centrum se například používá k optimalizaci časů zpá teční cesty médií pro zákazníky v asijských zemích, kde mohou být zpáteční časy do Austrálie nebo Japonska neoptimální. Datová centra jsou propojená multigigabitovou a plně redundantní páteří. Obrázek globálně distribuovaných datových center ukazuje přehled všech datových center. Nejnovější seznam dostupných datových center najdete v části Umístění datových center pro Webex Calling.

Globálně distribuovaná datová centra

Každý zákazník je zřizován v jedné z instancí. Veškeré informace o zřizování daného zákazníka jsou uloženy v této instanci a signalizace SIP všech koncových bodů a místních bran zřízených pro tohoto zákazníka je vázána na instanci, ve které je zákazník zřizován. Protože je těžké změnit počáteční výběr regionu, je důležité zvážit všechny relevantní faktory jako součást rozhodovacího procesu vedoucího k výběru regionu. Aby se zabránilo nadměrnému zpoždění zpáteční signalizace, je důležité rozhodnout se na začátku procesu přechodu, která instance by měla být použita. Společnost Cisco doporučuje vybrat instanci, která poskytuje nejnižší doby signalizace zpáteční cesty pro největší počet uživatelů v rámci nasazení.

Dostupnost v zemi naleznete v části Kde je Webex k dispozici? .

Lokality

Pro přípravu na přidělování umístění je třeba shromáždit požadované informace pro všechna cílová umístění migrace. Informace potřebné pro každé místo jsou shrnuty v Informace, které je třeba zachytit pro každé místo.
Tabulka 1. Informace, které je třeba zachytit pro každé místo
Informace Komentář
Rozsah (y) rozšíření Každé umístění může mít rozšíření začínající různými číslicemi. Jedna číslice musí být ušetřena pro číslici řízení mezi místy (například 8) a jedna pro číslici řízení PSTN (například 9). Žádný rozsah rozšíření nemůže začínat žádnou z těchto dvou číslic.
Všechny rozsahy rozšíření všech umístění musí mít stejnou délku.
Rozsah (y) DID -
Číslice řízení PSTN -
Kód webu Všechny kódy stránek všech míst musí být jedinečné a mít stejnou délku.
Hlavní číslo Při vytváření umístění je třeba zřídit dva DID. Jedno jako hlavní číslo (například přiřazené službě automatické obsluhy) a jedno pro portál hlasové sch ránky.
Zajistěte jeden DID pro číslo hlasové schránky.
Číslo hlasové schránky
Počet licencí Požadované licence podle typu včetně Standard, Professional, Workspace, Route List, Outbound Calling Plan.
Souběžné hovory v rušné době Součet souběžných hovorů mezi zařízeními a mezi zařízeními a místní bránou (PSTN a volání do zařízení). Potřebné k určení požadované šířky pásma přístupu k internetu.
Země -
Časové pásmo -
Jazyk -
Kontakt (jméno, telefon, e-mail) -
Adresa (ulice, město, stát, PSČ) -
Fyzické odeslané umístění záchranných služeb pro koncové body Místo odeslání zařízení používané pro tísňové volání obecně zahrnuje následující: adresa budovy, adresa budovy+číslo patra, adresa budovy+číslo apartmá nebo adresa budovy + číslo podlaží + číslo kanceláře/kubické číslo.
Jedinečné fyzické umístění v síti na zařízení pro tísňové služby Fyzické umístění sítě pro tísňové volání obecně zahrnuje následující: přepínač/switchport pro kabelová zařízení, identifikátory základní sady služeb (AP) bezdrátového přístupového bodu (BSSID) pro bezdrátově připojená zařízení a/nebo místní podsítě IP pro koncová zařízení.

PSTN

Při navrhování nasazení mají zákazníci tři primární možnosti připojení PSTN: Cisco C alling Plans (cloudová služba PSTN spravovaná společností Cisco), Cloud Connec ted PSTN Providers (CCPP, kde poskytovatelé poskytují službu PSTN prostřednictvím cloudu) a místní PSTN (kde místní brány propojují podnikovou síť s PSTN). Se zavedením trunkingu PSTN pro hybridní nasazení (Další informace viz trunking PSTN pro hybridní nasazení při trunkování PSTN) získávají organizace Webex Calling další flexibilitu ve svém přístupu k migr aci. Tato funkce umožňuje zákazníkům přesunout své PSTN na CCPP na začátku cesty přechodu a začít přecházet na cloudové PSTN pro uživatele, přičemž využívá CCPP k udržení služby PSTN pro uživatele, kteří zůstávají na Cisco během postupné migrace.

Tento hybridní přístup umožňuje organizacím přesunout vybrané skupiny uživatelů do cloudu jako první, aniž by okamžitě přepracovaly celé své telefonní prostředí. Zavádí však další složitost a riziko, zejména pokud jde o přizpůsobení stávající logiky směrování hovorů na podporu nové architektury. Interoperabil ita se staršími aplikacemi, jako jsou faxové servery, kontaktní centra nebo stránkovací systémy, také vyžaduje pečlivé zvážení. Klíčové technické výzvy mohou zahrnovat zajištění bezproblémového vyjednávání kodeků typu end-to-end a signalizace DTMF (Dual-Tone Multi-Frequency) napříč smíšeným prostředím, stejně jako ověření kompatibility se specializovanými telefonními funkcemi. Správ né plánování a testování jsou nezbytné pro minimalizaci narušení a udržení spolehlivých hlasových služeb v průběhu procesu migrace. Kromě toho jsou důležité obchodní aspekty, protože hybridní trunking vyžaduje licenci pro použití, která je založena na počtu souběžných hovorů mezi místním prostředím a poskytovatelem služby PSTN (CCPP) připojeným k cloudu.

Alternativně, organizace se mohou rozhodnout zachovat své místní připojení PSTN po celou dobu přechodové fáze. V tomto scénáři lze migraci na CCPP provést dvěma způsoby: jako jeden koordinovaný přechod pro všechny uživatele a umístění po dokončení migrace, nebo přírůstkově, přičemž migrace PSTN probíhá na základě jednotlivých lokalit při přesunu uživatelů. Tento přístup může pomoci zefektivnit koexistenci a zachovat kontinuitu pro starší integrace, ale přináší několik provozních složitostí. Mezi ně patří výzvy související s přenosem čísel, jako je potřeba přesné koordinace objednávek číselných portů, potenciální zpoždění, a omezení uložená poskytovatelem, jako je omezení počtu souběžných požadavků na port nebo omezení přenosu podmnožin velkých číselných bloků. Organizace musí pečlivě naplánovat svou strategii přechodu na PSTN s přihlédnutím k těmto logistickým aspektům, aby se zabránilo přerušení služeb a zajistily hladkou migraci.

Migrace na CCCP na začátku vs. zachování místního PSTN

Obrázek Migrace na CCCP na začátku vs. zachování místního PSTN ukazuje dvě možnosti migrace PSTN vysvětlené výše. Obrázek vlevo ukazuje scénář, kdy všichni místní uživatelé a aplikace Webex Calling využívají služby PSTN připojené ke cloudu prostřednictvím místního kmene a místní brány připojující místní bránu, zatímco obrázek vpravo ukazuje scénář, kdy stávající místní PSTN zůstane na svém místě a uživatelé používají místní PSTN prostřednictvím připojení místní brány mezi místními služ bami a. Během přechodu lze přepnout umístění pomocí Cloud Connected PSTN.

V obou scénářích volání mezi místním a uživatelem využívají připojení místní brány. Spojení mezi místními a místními zařízeními musí být navrženo a dimenzováno odpovídajícím způsobem na základě očekávaného počtu souběžných ho vorů a požadované redundance.

Číselný plán

Aby bylo dosaženo bezproblémové interoperability mezi obdobím migrace a během něj, musí být vyvinuta a implementována komplexní architektura číselného plánu na obou platformách. Tento návrh číselného plánu s dvěma platformami zajišťuje konzistentní směrování hovorů, překlad čísel a transparentnost funkcí, což uživatelům v obou systémech umožňuje komunikovat bez zhoršení služeb nebo narušení uživatelské zkušenosti během fáze koexistence.

Místní vytáčecí plán v

Během přechodu, aby umožnila koexistenci zařízení registro Unified CM vaných na a na podnikovém číselném plánu je třeba změnit tak, aby bylo možné splnit alespoň následující požadavky:

+E.164 vytáčení z do

Rozšířená volba z do (uvnitř pracoviště, ale také mezi pracovišti, pokud jsou rozsahy rozšíření jedinečné)

Zkrácená volba mezi místy z do

Vynucené vytáčení přes síť z do

Zpětné volání z adresáře zmeškaných hovorů do cílových míst

Volání PSTN z PSTN, pokud se během přechodu používá místní PSTN

Volání PSTN z do if během přechodu se používá trunking PSTN pro hybridní nasazení k zajištění přístupu PSTN místním uživatelům prostřednictvím služby Cloud Connect pro

Vynucené připojení k síti od do

Rozšířená volba z do (mezi místy).

Pokud některý z výše uvedených návyků není podporován volací návyk před přechodem, například neexistuje žádný zkrácený zvyk vytáčení mezi místy, pak nemusí být nutně zaváděny během přechodu.

Číselný plán Osvědčené postupy znázorňuje osvědčené postupy pro vytáčecí plán, jak je popsáno v části Prefer ovaná architektura pro Cisco Collaboration 12.x Enterprise On-Premises Deployments, CVD. Mezi klíčové charakteristiky tohoto přístupu patří:

Jeden oddíl pro čísla adresářů+E.164

Směrování jádra založené na vzorcích tras +E.164

Normalizace všech volebních návyků na +E.164 pomocí překladových vzorů

Použití překladového vzoru volajícího dědičnost vyhledávacího prostoru (možnost Použít volající vyhledávací prostor původce nastaven ý na vzory překladu).

Osvědčené postupy pro vytáčecí plán

Například vytáčení PSTN (9+1+10D) ze zařízení v SJC zřízeném vyhledávacím prosto rem SJCinternational se nejprve přiřadí překladový vzor 9.1 [2-9] XX [2-9] XXXXXX, který normalizuje číslo volané strany na +E.164. Sekundární vyhledávání pak znovu použije stejný volající vyhledávací prostor SJCinternational (vyvolává dědičnost vyhledávacího prostoru) a řetězec +E.164 bude buď přiřazen číslem adresáře +E.164 v oddílu DN, nebo jedním ze vzorů trasy PSTN v oddílu USPSTNNational nebo SJCPSTNLocal. Zkrácené návyky vytáčení uvnitř a mezi místy jsou implementovány překlady v oddílu ES N a SJCTOE164. Zatímco oddíl ESN je globální oddíl (přístupný pro telefony ve všech umístěních), oddíl SJCTOE164 je přístupný pouze uživatelům v umístění SJC. To předpokládá překrývající se rozsahy rozšíření.

Prvním krokem k povolení volání z do je zajistit, aby cíle +E.164 byly odpovídajícím způsobem směrovány. Toho lze dosáhnout přidáním oddílu do číselného plánu, přidáním vzorů trasy +E.164 pro všechny cíle do tohoto oddílu a nakonec přidáním oddílu do všech volajících vyhledávacích prostorů představujících třídy služeb, které je třeba dosáhnout. Vytvoření vyhrazeného oddílu je nutné, aby bylo možné vytvořit diferencovanou třídu služeb pro volání pocházející z. Aby se zabránilo smyčkám volání, nemělo by mít vyhledávací prostor pro příchozí volání v kmeni z místní brány přístup k oddílu.

+E.164 směrování do Webex Calling

Jak je znázorněno na obrázku +E.164 směrování doWebex Calling, aby bylo možné směrování z do pro umístění s rozsahem +E.164 DID +1 221 555 2XXX a kódem lokality 121, je třeba do oddílu přidat urgentní vzor trasy odpovídající tomuto rozsahu+E.164.

Pokud není vyžadován žádný výběr místní brány pro konkrétní lokalitu, pak místo použití seznamu tras s místní skupinou tras jako cíle pro vzory tras ukazující na jednu skupinu tras lze zřídit s místní bránou jako jediným členem a poté vzory tras odkazují na jeden seznam tras s touto jedinou skupinou tras jako jedinou položkou.

Pro povolení zkrácené vytáčení mezi lokalitami je do oddílu přidán požadovaný vzor tras y 8121.2XXX. Pro lokality, které mají být převedeny na normalizační vzorec vytáčení 8121.2XXX, který normalizuje volbu ESN na +E. 164, již mohou existovat v oddílu ESN. V takovém případě se 8121.2XXX jeví jako nadbytečný, ale jakmile budou všechny DN příslušného umístění migrovány na normalizaci vytáčení 8121.2XXX, lze odstranit vzor překladu a pak vzor trasy 8121.2XXX umožní vytáčení ESN i pro uživatele pouze z rozšíření v daném rozsahu.

S těmito změnami číselného plánu lze volání do lokality uskutečňovat nejen vytočením zkráceného inter-site a +E.164. Také mezinárodní a národní vytáčení PSTN je možné, protože tyto návyky vytáčení jsou nejprve normalizovány na +E.164 prostřednictvím již existujících vzorů normalizace vytáčení a poté jsou směrovány porovnáním vzoru trasy +E.164 v oddílu.

Odpovídající vzor trasy +E.164 v rozsahu DID umístění lze zřídit, dokud jsou všechny DID stále hostovány zapnuté. Algoritmus párování vzorů nejlepší shody zajišťuje, že když je vytočeno číslo hostované na, bude číslo adresáře +E.164 zřízené lépe odpovídat než vzor trasy +E.164 se zástupným znakem ukazující na, takže hovory budou rozšířeny na linku zapnutou a ne odeslány.

číselný plán

Každému uživateli je přiděleno rozšíření a/nebo telefonní číslo +E.164. Délka rozšíření je pevné globální nastavení: všechna rozšíření v rozmístění mají stejnou délku. Rozšířené vytáčení lze použít mezi uživateli jak v rámci místa, tak mezi místy. Zkrácená volba mezi pobo čkami (druhý případ) funguje pouze v případě, že je vytočené rozšíření jedinečné.

Pokud je požadavkem zkrácené vytáčení mezi lokalitami, ale mezi rozšířeními přiřazenými v různých umístěních dochází k překrývání, je třeba vytvořit plán číslování specifický pro podnik tak, že rozšíření předponou přístupovým kódem a kódem webu. Další informace naleznete v tématu Preferovaná architektura pro místní nasazení Cisco Collaboration 15, Přehled návrhu dostupný na adrese Preferované architektury spolupráce společnosti Cisco.

Délka rozšíření, chování vytáčení mezi místy, délka předpony pro vytáčení mezi místy a číslice řízení v předponě směrování pro vytáčení mezi místy jsou nakonfigurovány v nastavení volací služby v:

Délka předpony směrování polohy: Délka předpony včetně číslice řízení. Vyžad uje se pouze v případě, že je třeba vytvořit plán podnikového číslování jako alternativní zkrácený podnikový zvyk vytáčení mezi lokalitami.

Číslice řízení v předponě směrování: Ř ídící číslice pro zkrácený podnikový zvyk vytá čení mezi místy. Je třeba se vyhnout překrývání s první číslicí libovolného místa a čísli c odchozího vytáčení polohy. Vyžad uje se pouze v případě, že je třeba vytvořit plán podnikového číslování jako alternativní zkrácený podnikový zvyk vytáčení mezi lokalitami.

Vnitřní délka prodlou žení: Standardní délka nástavců. Může být libovolná hodnota mezi dvěma a deseti.
Pokud je z místního řízení hovorů vyžadováno vytáčení nebo vytáčení pomocí podnikových významných čísel (kód řízení, kód lokality, rozšíření) a místní řízení hovorů odešle rozšíření jako ID volajícího, nezapomeňte také nastavit parametr Maximální neznámá délka rozšíření v části Směrování hovorů mezi místními místy a místními místy, aby bylo zajištěno, že volání z místního řízení hovorů lze správně klasifikovat jako místní hovory.

Povolit vytáčení z pobočky mezi místy: Přepnutím povolíte nebo zakážete vytáčení z pobočky mezi místy . Tato možnost by měla být povolena pouze v případě, že všechna rozšíření v organizaci jsou jedinečná. Pokud je tato možnost zakázána, je třeba mezi místy vytočit podniková významná čísla (kód řízení, kód webu, přípona) nebo telefonní čísla.

První tři parametry se používají hlavně k vytvoření číselného plánu pro telefony, aby se minimalizovaly mezimístné časové limity při použití off-hook vytáčení. Odchylky od těchto globálních nastavení jsou stále možné (Příklad - lze zřídit rozšíření s jinou délkou), ale v ovládacím centru se zobrazí varovná zpráva a vytáčení z telefonů může vyžadovat blokovanou volbu, aby se předešlo konfliktům v předinstalovaném číselném plánu.

Příklad číslování v tabulce Enterprise ukazuje příklad tří míst, kde jsou rozsahy rozšíření dvou míst, NYC a RTP, identické. Vytvoření schématu číslování podniků s číslicí řízení mezi pracovišti 8, následovaným třímístným kódem webu, a čtyřmístné rozšíření vytváří nepřekrývající se zkrácený zvyk vytáčení mezi weby.

Tabulka 2. Příklad podnikového číslování
Stránky Rozšiřující rozsah Kód webu Řada Enterprise

NYC 2XXX 202 8 202 2XXX

SFO 3XXX 203 8 203 3XXX

RTP 2XXX 204 8 204 2XXX

Aby byl umožněn hladký přechod, sada volacích návyků pro uživatele před a po přechodu na ideálně by měla být stejná. Pro přípravu na přechod pro každé místo je třeba zdokumentovat rozsa hy DID a rozsahy rozšíření (nebo zkrácené návyky vytáčení uvnitř místa). Na základě těchto informací je třeba vybrat číslici řízení mezi pracovišti.

Tabulka Rozsahy prodloužení pevných dé lek ukazuje příklad tří umístění a rozsahů prodloužení s pevnou délkou. Vzhledem k tomu, že je třeba se vyhnout překrývajícím se volacím návykům, je důležité se ujistit, že pro jakýkoli rozsah rozšíření se první číslice rozsahu neshoduje s číslicí řízení pro zkrácenou volbu mezi místy. Pokud je například 8 vybrána číslice řízení pro vytáčení mezi místy, pak žádný rozsah rozšíření na žádném místě nemůže začínat číslem 8. Typicky, rozšíření v daném místě odpovídají posledním číslicím DID přiřazených tomuto umístění. Aby se předešlo konfliktům, lze změnit první číslici rozšíření. Pokud jsou například DID v rozsahu +1 408 555 8XXX použity v určitém umístění, pak místo použití 8XXX jako rozšíření lze použít 7XXX pro rozšíření v daném webu

Tabulka 3. Rozsahy prodloužení pevných délek
Stránky Rozšiřující rozsah Rozšíření Kód webu Řada Enterprise

NYC 2XXX 2XXX 202 8 202 2XXX

SFO 8XXX 7XXX 203 8 203 7XXX

RTP 1XX 11XX 204 8 204 11XX

Sedmimístné číselné řetězce vytočené na zařízení pomocí amerického číselného plánu se překrývají se sedmimístným vzorem pro místní vytáčení v předinstalovaném americkém číselném plánu. Aby se zabránilo překrývání mezi jakýmikoli zvyky vytáčení v síti a mimo síť (PSTN), lze v tomto místě použít povinný externí přístupový kód. Pokud se stávající schéma číslování podniků a odpovídající zkrácené vytáčení mezi místy překrývají se vzory v národním číselníku, pak během přechodu na schéma číslování, aby se zabránilo překrývání, lze také změnit na delší nebo kratší formu. Nej jednodušší způsob, jak toho dosáhnout, je přidat další polstrovanou číslici do schématu číslování. Nové delší schéma vytáčení mezi weby musí přijmout pouze uživatelé, na které již migrovali. Uživatelé, kteří jsou stále zapnuti, mohou i nadále vytočit sedm číslic. V tomto případě musí být zapnutý podnikový vytáčecí plán zajistit, aby zkrácená sedmimístná volba z do byla převedena buď Unified CM na +E.164, nebo na zkrácený formát vytáčení nasazený na. To je třeba provést před odesláním hovoru na místní bránu.

Příklad tohoto přečíslování ukazuje sedmimístný přecho d tabulky. V tomto příkladu používá zkrácená volba mezi místy číslici řízení 8 následovaná dvoumístným kódem webu a čtyřmístným rozšířením. Aby se zabránilo sedmimístnému zkrácenému vytáčení mezi místy pro místa na, lze kódy stránek snadno změnit na tři číslice předponou libovolné polstrovací čí slice (8 v příkladu) k dvoumístným kódům stránek použitým v, takže volba mezi místy z telefonů používá číslici řízení 8 následovanou polstrovací číslicí 8, starý dvoumístný kód webu, a čtyřmístné rozšíření. Uživatelé si nemusí pamatovat nové kódy stránek; stačí si pamatovat použít 88 jako předponu pro vytáčení mezi weby místo 8 zapnuto.

Tabulka 4. Přechod sedmimístné volby

Stránky Rozšíření Kód webu Řada Enterprise Stránka óda Enterprise Angle

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

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

RTP 1XXX 24 8 24 11XX 824 8 824 11XX

Ve scénáři se zapnutými různými formáty podnikových čísel a pokud jsou podniková čísla prezentována jako informace volající strany pro volání z do (například volání ze zařízení bez DID), je důležité implementovat také mapování mezi různými formáty čísel pro informace volající strany, aby bylo zajištěno, že zpětné volání funguje. Tohoto mapování lze dosáhnout použitím vzoru transformace volající strany na kmeni mezi a místní bránou.

Nahrávání

Dobře navržené řešení nahrávání hovorů vyžaduje pečlivé zvážení několika klíčových konstrukčních prvků, aby bylo zajištěno, že je v souladu s organizačními cíli, regulačními požadavky a technickými omezeními. Dvě z nejdůležitějších rozhodnutí zahrnují výběr poskytovatele a výběr regionu, které může být nutné globálně přizpůsobit a přepsat na konkrétních místech, na základě obchodních potřeb.

1. Výběr poskytovatele nahrávání hovorů

Výběr vhodného poskytovatele nahrávání hovorů je zásadní pro splnění obchodních cílů a zajištění sladění funkcí v celé organizaci:

Výběr globálního poskytovatele: Organizace obvykle určují primárního poskytovatele nahrávání hovorů na globální úrovni, což zajišťuje konzistenci sady funkcí, dodržování předpisů a podpory ve všech lokalitách

Přepsání podle polohy: Ve scénářích, kdy konkrétní lokality nebo oblasti mají jedinečné obchodní potřeby nebo regulační požadavky, může být nutné přepsat globální výběr poskytovatele a určit alternativní poskytovatele pro tato místa. Tato flexibilita podporuje různé mandáty dodržování předpisů a místní provozní potřeby

Obchodní požadavky: Volba poskytovatele by měla být řízena posouzením faktorů podnikání, jako je dodržování předpisů (příklad — MiFID II, HIPAA), zajištění kvality, řešení sporů nebo potřeby školení

Dostupnost funkcí: Poskytovatelé by měli být vyhodnocováni na základě jejich schopnosti poskytovat požadované funkce, jako je monitorování v reálném čase, možnosti vyhledávání a přehrávání, šifrování, zásady uchovávání údajů, integrace s analytickými platformami a podpora různých typů hovorů (příchozí, odchozí, interní).

2. Výběr regionu

Určení oblasti, kde jsou záznamy hovorů uloženy a zpracovávány, je rozhodující pro dodržování předpisů a výkon:

Globální výběr regionu: Ve výchozím nastavení mohou organizace zvolit jednu oblast pro ukládání záznamů hovorů, aby se zjednodušila správa a správa

Přepsání oblastí podle polohy: Pokud to vyžadují zákony o pobytu dat nebo firemní zásady, může být nutné přepsat globální nastavení regionu pro konkrétní místa a zajistit, aby záznamy hovorů byly uloženy a zpracovávány v požadovaných geografických hranicích

Požadavky na umístění dat: Návrh musí zohledňovat mezinárodní a místní předpisy o ochraně údajů (jako je GDPR, CCPA nebo mandáty specifické pro jednotlivé země), které mohou určovat, kde a jak budou záznamy hovorů uchovávány.

Dalším kritickým aspektem, který je třeba řešit při plánování a návrhu řešení pro nahrávání hovorů, je odhad požadavků na úložiště. Přesné předpovídání potřeb úložiště je zásadní pro zajištění dostatečné kapacity pro podporu probíhajících obchodních operací, zachování souladu s předpisy a zabránění přerušení služeb.

Při určování očekávané poptávky po skladování je třeba vzít v úvahu několik klíčových parametrů:

Objem nahraných hovorů: Posoudit očekávaný počet hovorů, které budou zaznamenány v daném časovém intervalu (např. za den, týden nebo měsíc). To zahrnuje nejen externí hovory, ale také interní komunikaci, pokud to vyžaduje obchodní politika nebo regulační mandáty

Průměrná délka hovoru: Vy počítejte typickou délku zaznamenaných hovorů, protože delší hovory spotřebovávají více úložného prostoru. Odchylky v délce hovoru mezi různými odděleními nebo skupinami uživatelů by měly být také zohledněny do odhadu

Doba uchovávání: Definujte dobu, po kterou musí být záznamy uchovávány, což je často diktováno organizačními zásadami nebo externími předpisy (například standardy shody specifickými pro dané odvětví). Delší doba uchovávání zvýší celkové požadavky na skladování

Prognózy růstu: Zvažte očekávaný růst objemu hovorů nebo rozšíření rozsahu nahrávání, které může být důsledkem škálování podnikání, nových regulačních požadavků nebo začlenění dalších uživatelů nebo míst.

Důkladnou analýzou těchto parametrů mohou organizace vyvinout robustní strategii úložiště, která zajistí škálovatelnost, nákladovou efektivitu a dodržování předpisů pro jejich řešení pro nahrávání hovorů. Je také vhodné pravidelně kontrolovat a upravovat alokace úložiště, protože se vzorce využití v průběhu času vyvíjejí.

Tísňové volání

Požadavek na směrování tísňového volání do příslušného dispečerského střediska je požadavkem pro jakoukoli volací službu, která nabízí službu PSTN. S, směrování tísňových hovorů je nativní pro řešení a zahrnuje podporu pro všechna národní čísla tísňového volání v zemích, které podporují. Směrování tísňového volání je založeno na umístění definovaném uvnitř a metodě přístupu PSTN místa. Čísla tísňového volání jsou předdefinovaná a specifická pro zemi, ve které jsou uživatelé a zařízení nasazeni.

Existují dva způsoby doručování tísňových hovorů. K dispozici je základní služba směrování tísňového volání a rozšířená služba směrování tísňových hovorů. Základní služba směrování tísňových hovorů použije číslo vybrané správcem k identifikaci polohy a trasy volání k dosažení tísňových služeb. Pro základní tí sňové volání je cesta volání obvykle prostřednictvím možnosti PSTN zákazníka pro danou místu. má také rozšířené směrování tísňových hovorů navržené pro nasazení v USA a Kanadě, která mají požadavky na dodržování předpisů, které vyžadují použití celostátního poskytovatele k doručování tísňových hovorů do správného dispečerského centra .

Všichni zákazníci by měli nasadit alespoň základní konfiguraci tísňového volání. Základní tísňové volání vyžaduje, aby každému místu definovanému v aplikaci bylo přiřazeno alespoň jedno číslo +E.164 vlast něné zákazníkem. Pro základní tísňové volání bude každé místo definováno adresou ulice, na kterou jsou v případě nouze vyslány policejní, hasičské nebo záchranné služby. Ve většině případů je hlavní číslo místa nejlepší volbou pro reprezentaci fyzického umístění nouze. Přiřazení adresy číslu +E.164 je obvykle koordin ováno s poskytovatelem PSTN. Níže uvedené obrázky ukazují přiřazení hlavního čísla, které má být použito jako číslo tísňového volání pro umístění Richardson.

Umístění konfigurace ECBN

Ve většině situací, adresa budovy postačuje pro adresu odeslání místa. Pokud jsou však pro konkrétní uživatele nebo zařízení potřebné další podrobnosti o poloze , může správce použít stejný postup popsaný výše a přiřadit tato zařízení ke konkrétní adrese nebo přesnějšímu umístění uvnitř adresy (například podlaží nebo místnosti). Ve správě uživatelů v aplikaci, karta Volání umožňuje použití konkrétního čísla pro uživatele a jeho zařízení k získání konkrétní adresy odeslání. Následující obrázky ilustrují, jak lze zařízení přiřadit konkrétní číslo. Správce je odpovědný za to, aby číslo používané zařízením mělo přiřazenou správnou adresu odeslání. Při řazení adresy se obvykle provádí prostřednictvím poskytovatele PSTN tohoto umístění.

Konfigurace uživatele ECBN

Pro nasazení telefonie v USA, která musí poskytovat vylepšená řešení tísňového volání, používá pro směrování tísňových hovorů integrovanou Horizon Mobility společnosti RedSky. Při použití RedSky pro směrování hovorů musí správce zaregistrovat účet prostřednictvím společnosti Cisco a nakonfigurovat příslušné informace v Volání -> Nastavení služby, aby tuto funkci povolil. Jakmile je služba RedSky povolena na úrovni systému, správce povolí službu RedSky na každé úrovni umístění. Povolení rozšířeného tísňového volání v místě aktivuje službu pro všechna zařízení, která jsou k danému umístění přiřazena. Zařízení podporující rozšířené tísňové volání jsou telefony Cisco MPP, telefony Cisco PhoneOS a Cisco.

Existují dvě nastavení pro povolení rozšířeného tísňového volání na místě. Polo žka Povolit RedSky přijímat informace o síťovém připojení a testovací volání by měla být použita k ověření správnosti konfigurace RedSky pro mapování zařízení a infrastruktury. Toto nastavení také umožňuje provádět testovací hovory na 933 za účelem ověření polohy pomocí systému IVR společnosti RedSky k odečtení polohy volajícího. Ačkoli tento dokument nebude pokrývat konfiguraci RedSky pro sledování polohy, správce by měl VŽDY otestovat zjištění své polohy před aktivací tísňových hovorů pro směrování na RedSky. Jakmile bude testování dokončeno a ověřeno jako přesné, správce směruje hovory na RedSky přepnutím tísňových volání na RedSky. Tento přepínač nasměruje všechna tísňová volání z místa na RedSky pro doručení do záznamníku pro dané místo.

Nastavení rozšířeného tísňového volání platí také pro místní i externí klienty. V místním prostředí lze sledovat stejným způsobem, jakým jsou sledovány stolní telefony. Pokud je uživatel mimo místní prostředí, bude moci dynamicky nastavit své umístění přímo v rámci. Další informace o tísňovém volání naleznete v tématu Vylep šené tísňové volání pro.

Licencování

Existuje několik možností, jak uživatelům přiřadit licence.

Ruční přiřazení přes

Administrátoři ručně přiřazují licence jednotlivým uživatelům prostřednictvím rozhraní.

Správci mohou upravovat licence služeb pro jednotlivé uživatele a přiřadit licence pro volání přímo.

Šablony automatického přiřazení licencí

Pomocí šablon přiřazení licencí můžete automaticky přiřadit licence uživatelům na základě nastavení skupiny nebo organizace.

Automatické licencování lze provádět prostřednictvím synchronizace adresářů nebo ručních uživatelských aktualizací, ale uživatelé musí mít platné telefonní číslo ve formátu +E.164 a telefonní čísla musí existovat v určitém místě před zřizováním uživatele. Pokud nejsou splněny podmínky (např. neplatný formát telefonního čísla), licence nebudou přiřazeny.

Hromadné přiřazení prostřednictvím šablony CSV

Nahrajte soubor CSV s podrobnostmi o uživateli a přiřazením licencí, abyste přid ali nebo upravili více uživatelů najednou.

Import CSV podporuje přidání až 20 000 uživatelů a přiřazování licencí, ale licence vyžadují specifická pole, jako je telefonní číslo a přípona.

Přiřazení na základě rozhraní API

Pomocí rozhraní API můžete programově přiřadit licence a spravovat uživatele.

podporuje operace API pro správu uživatelů a licencí (People, SCIM 2.0 a Licences API), které lze využít pro automatizaci přiřazování licencí. Licenční API umožňuje současné přiřazování licencí, telefonních čísel a rozšíření.
Tabulka 5. Možnosti zřizování uživatelů - souhrn
Metoda přiřazení Klady Nevýhody
Manuální přes Jednoduché pro několik uživatelů.
Umožňuje přesnou a podrobnou kontrolu nad přiřaz ením licencí.
Není škálovatelný, časově náročný
Při ručním zadávání je náchylný k lidské chy bě.

Automatické šablony licencí Škálovatelný
Snižuje manuální chyby
Lze použít pro nové i stávající uživatele.
Vyžaduje platná telefonní čísla a místa.
Složitější nastavení
Vyžaduje také skupiny uživatelů na skupinu uživatelů s ekvivalentními licenčními požadavky.

Hromadné nahrávání CSV Efektivní pro velké uživatelské sady
Umožňuje současné přiřazování licencí, telefonních čísel a rozšíření.
Vyžaduje pečlivé formátování CSV
Potenciál chyb, pokud telefonní čísla nebo přípony chybí nebo jsou nesprávné.
Přiřazení na základě rozhraní API Automatizovatelný, flexibilní.
Umožňuje současné přiřazování licencí, telefonních čísel a rozšíření.
Vyžaduje vývoj a znalosti API.

Tabulka Možnosti zřizování uživatelů - souhrn shrnuje možnosti zřizování uživatelů a jejich klady a zápory. Tento přehled pomáhá vybrat nejlepší metodu přiřazení licencí na základě velikosti organizace zákazníka, možností automatizace a procesů a požadavků na zřizování uživatelů.

Pokud je to možné, společnost Cisco doporučuje přiřadit licence pro volání pomocí šablon licencí. To vyžaduje, aby pro každou skupinu uživatelů vyžadovala jedinečnou sadu licencí (Příklad - Standardní vs. Profesionální) existuje skupina s příslušným členstvím ve skupině. Jak je popsáno v oddílech Skup iny uživatelů, skupiny uživatelů lze definovat ručně nebo synchronizovat z podnikového adresáře. Kombinace obou přístupů je možná.

Uživatelé patřící do více skupin získávají licence ze všech přiřazení aplikovaných na všechny jejich skupiny. To umožňuje používat skupiny zabezpečení specifické pro licenci v podnikovém adresáři ke správě přiřazování licencí, kde je výsledné přiřazení uživatelské licence řízeno spojen ím členství ve skupině.

Další informace naleznete v tématu Nastavení automatického přiřazení licencí v Řídicím centru a Nastavení šablon automatického přiřazování licencí pro Webex Calling uživatele.

Požadavky na licenci

Tato část se zabývá pouze souvisejícími licencemi. Jiné typy licencí (Příklad - registrace zařízení Webex, zasílání zpráv, schůzky) nejsou zahrnuty. V rámci procesu návrhu je třeba stanovit licenční požadavky. Je třeba vypočítat počet licencí pro následující typy licencí:

Standard: počet jednotlivých uživatelů vyžadujících standardní telefonní funkce.

Profesionální: počet uživatelů a pracovních prostorů vyžadujících pokročilé funkce telefonování. Virtuální linky a skupinová hlasová schránka mají nárok na poměr 1:1 pro každou profesionální licenci. Proto ve vzácných případech, kdy počet požadovaných virtuálních linek nebo skupinových hlasových zpráv převyšuje počet uživatelů a pracovních prostorů vyžadujících pokročilé funkce telefonování, je třeba počítat s dalšími profesionálními licencemi.

Pracovní prostor pro společnou oblast: počet sdílených použití nebo míst ve společných prostor ách vyžadujících standardní možnosti volání.

Zákaznická pomoc: počet agentů a supervizorů vyžadujících funkce Customer Assist. Zákaznická pomoc zahrnuje licenci Professional.

Volání seznamu tras: počet požadovaných hovorů PSTN připojených ke cloudu mezi místními uživateli a/nebo místními specializovanými aplikacemi třetích stran.

Konzola obslu hy: počet uživatelů, kteří vyžadují přístup ke klientovi konzoly obsluhy.

Plán volání Cisco (plán odchozího volání): počet uživatelů, kteří vyžadují číslo PSTN a/nebo odchozí přístup k volání PSTN pro službu Cisco PSTN.

Pro profesionální pracovní prostory neexistuje žádný vyhrazený typ licence. Profesionální pracovní prostory spotřebovávají licenci Professional.

Pracovní prostory pouze na pracovišti typu hot-desk nabízejí hostitelskou službu hot-desking a tísňové volání z hostitele hot-desking a nevyžadují žádnou licenci. Další informace naleznete v tématu Přidání a správa zařízení pouze pro pracovní stůl.

Chcete-li určit požadovaný typ licence pro každého uživatele a pracovní prostor na základě potřebných funkcí, přečtěte si článek Funkce dostupné podle typu licence pro Webex Calling.

Chcete-li rozlišit mezi funkcemi nabízenými frontami volání v kombinaci s profesionální licencí na rozdíl od zákaznické asistence, viz Porov nání funkcí fronty ho Webex Calling vorů a zákaznické asistence.

Zřizování uživatelů

Při zřizování uživatelů ve Webexu je k dispozici několik možností, z nichž každá vyhovuje různým potřebám a prostředím organizace:

Ruční zřizování: Správci mohou přidávat a spravovat jednotlivé uživatele přímo uvnitř. Tato metoda je přímočará, ale nejvhodnější pro malé organizace nebo omezené změny uživatelů.

Hromadné zřizování prostřednictvím CSV: U větších uživatelských základen mohou správci hromadně importovat a aktualizovat uživatele nahráním souborů CSV do. To umožňuje efektivní správu až tisíců uživatelů najednou.

Možnosti synchronizace adresářů:
Adresářový konektor: Jedná se o automatický synchronizační nástroj používaný v Microsoft Active Directory prostředích. Synchronizuje uživatelské účty, skupiny a atributy na plánovaně (hodinově, denně nebo týdně). Podporuje nastavení více domén a více doménových struktur Active Directory a může synchronizovat obrázky profilů a objekty místnosti.

Aplikace průvodce Entra ID (Azure AD): Tato metoda je navržena pro organizace používající Microsoft Entra ID (Azure AD) a poskytuje automatickou synchronizaci uživatelských účtů a atributů téměř v reálném čase přímo z Entra ID do. Je plně spravován uvnitř a vyžaduje minimální nastavení.

Aplikace SCIM 2.0: V prostředích jiných než Microsoftu nebo jiných poskytovatelů identit, jako je Okta nebo Duo, umožňují synchronizační aplikace založené na SCIM automatické zřizování a deaktivaci uživatelů s mapováním atributů a synchronizací skupin.

Unified CMsynchronizace uživatelů: Tato možnost umožňuje vytvářet uživatelské účty založené na existujících koncových uživatelích synchronizací z do. To vyžaduje, aby v místních clusterech bylo spuštěno řešení Cloud Connected UC (CCUC). Obecně se však doporučuje synchronizovat uživatele z centralizovaného cloudového adresáře, jako je Entra ID, spíše než přímo z.

Zřizování API: Veřejná API (People, SCIM 2.0) lze použít k zřízení uživatelů. Hlavní výhodou používání rozhraní API je možnost integrovat zřizování uživatelů s jinými podnikovými systémy.
Tabulka 6. Možnosti zřizování uživatelů pro
Způsob poskytování Popis Klady Nevýhody
Manuál Vytvářet/spravujte uživatele jednotlivě v Jednoduché pro několik uživatelů; není potřeba žádná infrastruktura Není škálovatelný; časově náročné pro mnoho uživatelů
Hromadné (soubor CSV) Importujte/aktualizujte uživatele hromadně prostřednictvím CSV Efektivní pro skupiny; není nutné kódování Manuální příprava CSV; méně dynamické
Lidé a SCIM 2.0 API Programová správa uživatelů prostřednictvím rozhraní API Webex Flexibilní; podporuje automatizaci a integraci Vyžaduje rozvoj a infrastrukturu
Synchronizace adresářů Automatická synchronizace z aplikací AD, Entra ID, SCIM, Unified CM Automatizuje životní cyklus; podporuje filtrování a mapování Složitost nastavení: některé možnosti mají omezené funkce nebo vyžadují infrastrukturu
Tento přehled a tabulka odrážejí hlavní možnosti zřizování uživatelů, jejich výhody a omezení, které vám pomohou vybrat nejlepší přístup pro potřeby vaší organizace.

Skupiny uživatelů

Správa skupin uživatelů v aplikaci umožňuje správcům organizovat uživatele do skupin pro efektivní hromadnou správu licencí, nastavení a zdrojů. Skupiny pomáhají zjednodušit správu tím, že apli kují zásady, licence a šablony nastavení na více uživatelů současně, namísto správy uživatelů jednotlivě.

Správa skupin uživatelů nabízí několik výhod, včetně:

Zjednodušená správa: Spravujte licence, nastavení a zásady pro více uživatelů najednou.

Konzistence: Použijte jednotná nastavení a licence pro uživatele ve stejné skupině.

Škálovatelnost: Podporuje až 250 000 členů na skupinu.

Integrace: Synchronizujte skupiny z Microsoft Entra ID (Azure AD) nebo Active Directory pro automatizovanou správu uživatelů a skupin.

Flexibilita: Vytvářejte místní skupiny nebo synchronizujte skupiny zabezpečení; spravujte členství ve skupině ručně nebo prostřednictvím souborů CSV.

Přidělení zdrojů: Řízení přístupu k vloženým aplikacím a službám na základě členství ve skupině.

Hlavní případy použití skupin uživatelů při zřizování jsou:

Přiřazení lic encí: Přiřaďte licence skupinám, abyste členům skupiny automaticky poskytovali služby, jako jsou volání, schůzky, zasílání zpráv nebo hybridní služby.

Šablony nastavení: Použijte kolekce nastavení služeb (např. zasílání zpráv, schůzky, volání) na skupiny pro konzistentní uživatelský komfort.

Hromadná správa uživatelů: Hromadné přidávání nebo odebrání uživatelů prostřednictvím souborů CSV nebo synchronizace adresářů.

Automatizace a integrace: Použijte API nebo synchronizaci adresářů pro automatizovanou správu životního cyklu uživatelů a skupin.

Následující tabulka shrnuje různé možnosti správy skupin uživatelů a správy skupin v aplikaci.
Tabulka 7. Možnosti správy skupin a členství ve skupině
Varianta Popis Klady Nevýhody

přidělování skupin (skupiny) Vytvářejte a spravujte skupiny přímo v. Přidávání/odebrání členů ručně nebo prostřednictvím CSV. Plná kontrola nad členstvím ve skupině
Okamžitá aplikace licencí a šablon
Snadné vytváření a úpravy skupin Vyžaduje se ruční aktualizace
Riziko chyb při ručním nahrávání CSV
Žádná automatická synchronizace s externími adresáři

Synchronizované skupiny z Entra ID (Azure AD) nebo Active Directory Automaticky synchronizujte skupiny zabezpečení a členství z externích adresářových služeb. Automatizovaná synchronizace snižuje manuální práci
Zajišťuje konzistenci s podnikovým adresářem
Podporuje velké organizace
Nelze upravit členství ve skupině
Zpoždění synchronizace až 12 hodin
Vnořené skupiny vyžadují ruční výběr

Skupiny a SCIM 2.0 API (Skupiny) Použijte skupiny nebo rozhraní SCIM 2.0 API pro programovou správu skupin a členství Automatizace a integrace s jinými systémy
Škálovatelné pro velká nebo složitá prostředí
Vyžaduje vývojové úsilí
Složitost závisí na použití API

Zatímco synchronizované skupiny zajišťují konzistenci a nabízejí jediný bod správy, je možný hybridní přístup kombinující synchronizované skupiny a skupiny (buď spravované v řídicím centru nebo prostřednictvím rozhraní API). Například skupiny pro přiřazení licencí mohou být synchronizované skupiny a samostatná sada skupin může být použita pro přiřazení uživatelských a volajících šablon.

Tento komplexní přístup ke správě skupin uživatelů umožňuje organizacím efektivně spravovat uživatelské licence, nastavení, a zásady, což zajišťuje konzistentní a škálovatelné prostředí spolupráce.

Doporučený přístup při migraci z do

Primárním zdrojem dat pro uživatele je databáze, která obsahuje informace o koncovém uživateli. nicméně, obvykle není autoritativním zdrojem pro správu identit uživatele a co je důležitější, bude na konci přechodu vypnut, a proto je vyloučen jako dlouhodobý autoritativní zdroj informací o identitě.

Společnost Cisco doporučuje používat centralizovaný cloudový adresář, jako je Microsoft Entra ID (Azure AD), jako jediný zdroj pravdy pro identity uživatelů. Synchronizace uživatelů z Entra ID zajišťuje konzistenci, zjednodušuje správu a podporuje funkce jednotného přihlašování (SSO).

Aby bylo zajištěno, že všichni uživatelé jsou také přítomni v Entra ID, organizace by měly ověřit, zda uživatelské účty odpovídají účtům v Entra ID. To lze provést exportem seznamů uživatelů a jejich porovnáním se seznamy uživatelů Entra ID.

Stručně řečeno, doporučenou metodou zřizování je synchronizace uživatelů z Microsoft Entra ID (Azure AD) do Webex pomocí Průvodce Azure AD nebo aplikací SCIM. Ruční a hromadné zřizování souborů CSV jsou k dispozici jako doplňkové metody, ale pro velké organizace jsou méně škálovatelné a náchylnější k chybám. Zajištění, že Entra ID je autoritativním zdrojem a že všichni uživatelé existují v Entra ID, je zásadní pro úspěšnou migraci a konzistentní uživatelské prostředí napříč prostředími.

Přechod z místní adresářové služby, napříkladActive Directory, na cloudovou adresářovou službu, jako je Entra ID (Azure ID), je nezávislý na přechodu volání. Společnost Cisco doporučuje dokončit přechod na cloudovou adresářovou službu před zahájením přechodu volání.

Navrhování skupin uživatelů

Po přechodu podnikového adresáře z místního do cloudu sbírejte požadované skupiny uživatelů založené na požadavcích na licenci a šablonu funkcí. Pro každý skupinový dokument:

Název skupiny: jedinečný název skupiny.

Licence: licence, které mají být přiřazeny této skupině (pokud existují) a rozsah (měly by být licence přiřazeny stávajícím uživatelům nebo pouze novým uživatelům)

Šablony nastavení: Šablony volání aplikace Webex a uživatele.

Synchronizace adresářů: Bude tato skupina synchronizována z podnikového adresáře nebo se jedná o místní skupinu Webex zřízenou v Control Hub nebo prostřednictvím rozhraní API.

Popis: jak bude tato skupina používána a kteří uživatelé by měli být členy této skupiny

Tyto podrobnosti budou použity později během fáze implementace k vytvoření místních skupin nebo skupin v podnikovém adresáři a ke správě členství ve skupinách uživatelů.

Jednotné přihlášení (SSO)

Společnost Cisco doporučuje používat SSO pro ověřování uživatelů. Používání SSO má některé přesvědčivé výhody, včetně:

Zjednodušené ověřování uživatelů: Uživatelé se mohou jednou přihlásit pomocí svých firemních pověření (např. z Azure ID) a získat přístup k dalším integrovaným aplikacím, čímž eliminují potřebu více hesel a omezují výzvy k přihlášení. Tím se zvyšuje zabezpečení tím, že firemní hesla nebudou po ověření nikdy ukládána ani přenášena.

Zjednodušená správa uživatelů: Automatizuje vytváření uživatelských účtů, aktualizace a deaktivaci na základě změn v podnikovém adresáři, snižuje administrativní režii a zajišťuje přístup pouze oprávnění uživatelé.

Vylepšené zabezpečení: SSO snižuje únavu hesla a riziko narušení hesla centralizací ověřování prostřednictvím důvěryhodných poskytovatelů identit (IDP).

Snadná integrace vícefaktorové autentizace (MFA): MFA lze snadno podporovat buď prostřednictvím řešení Identity Access Management, jako je Cisco Duo, nebo prostřednictvím podpory M FA IdP.

Existuje několik možností implementace SSO pro služby:

SSO založené na SAML 2.0: Primární protokol podporovaný pro integraci SSO, který umožňuje bezpečnou výměnu ověřovacích informací mezi Id P a poskytovatelem služeb.

OpenID connect (OIDC): Podporováno jako alternativní moderní autentizační protokol pro integraci SSO.

Identita Webex: Pod porována také jako možnost poskytovatele identity.

SSO je konfigurováno a spravováno centrálně prostřednictvím, což vyžaduje výměnu metadat mezi vybraným IdP a vybraným IdP.

Po konfiguraci lze SSO před aktivací otestovat, aby bylo zajištěno správné nastavení.

Společnost Cisco podporuje integraci s několika testovanými a běžně používanými IDP a systémy správy identit (IAM), mimo jiné včetně:

Cisco Duo

Okta

Microsoft Active DirectoryFederační služby (ADFS)

Microsoft Azure

Ping Federate

OpenAM

F5 BIG-IP.

Tyto IDP odpovídají standardům SAML 2.0 nebo OpenID Connect a byly ověřeny z hlediska kompati bility s řešeními pro spolupráci Cisco.

Podpora více IdP

umožňuje organizacím konfigurovat SSO s více IDP tak, aby vyhovovaly složitým IT prostředím, jako jsou fúze, akvizice nebo decentralizovaná IT oddělení, kde různé skupiny používají různé IDP. Podpora více IdP může být implementována buď pomocí funkce Multiple IdP v nebo prostřednictvím integrace podnikového systému IAM, jako je Cisco Duo.

Podpora více poskytovatelů identit (IdP) řeší několik klíčových případů použití, kdy organizace vyžadují flexibilní a bezpečné ověřování napříč různými IT prostředími:

1. Fúze a akvizice

Když se společnosti spojují nebo získávají jiné, často mají oddělené IT infrastruktury a odlišné IDP, kteří se nemohou federovat. Podpora více IdP umožňuje uživatelům z obou organizací bezpečně ově řovat a spolupracovat, aniž by museli okamžitě sjednotit své systémy identity.

2. Více nezávislých IT oddělení

Velké organizace nebo vládní instituce mohou mít několik nezávislých IT oddělení, z nichž každý spravuje svůj vlastní IdP. Funkce více IdP umožňuje těmto oddělením udržovat vlastní autentizační systémy a zároveň uživatelům umožňuje bezproblémový přístup.

3. Různé skupiny uživatelů nebo domény

Organizace s různými skupinami uživatelů (např. zaměstnanci vs. dodavatelé) nebo s více e-mailovými doménami mohou nakonfigurovat pravidla směrování tak, aby požadavky na ověřování směrovaly na příslušného IdP na základě členství v doméně nebo skupině. To podporuje zásady diferencovaného přístupu a kontroly zabezpečení.

4. Podpora různých autentizačních protokolů

podporuje IDP SAML a OpenID Connect (OIDC), což organizacím umožňuje integrovat různé typy poskytovatelů identit podle jejich stávající infrastruktury a bezpečnostních požadavků.

5. Vylepšené zabezpečení a dodržování předpisů

Aktivací více IDP mohou organizace implementovat silnější ověřovací mechanismy, včetně vícefaktorového ověřování (MFA) prostřednictvím integrací, jako je Duo, a prosazovat konzistentní zásady zabezpečení napříč různými uživatelskými základnami.

6. Zjednodušené uživatelské prostředí

Uživatelé se mohou ověřovat pomocí svých stávajících přihlašovacích údajů od příslušných IDP, což poskytuje jednot né přihlašovací prostředí navzdory základní složitosti více systémů identity.

I když podpora více IdP poskytuje flexibilitu, vyžaduje pečlivou koordinaci mezi týmy zabezpečení a identity, aby byla zachována konzistentní bezpečnostní politika a zabránilo se potenciálním zranitelnostem.

Duo MFA s SSO pro

Duo Access Gateway (DAG) může ověřovat uživatele pomocí stávajících místních nebo cloudových adresářů, jako jsou Active Directory (AD) a OpenLDAP. Podporuje také integraci s dalšími poskytovateli identit, jako jsou Microsoft ADFS, Microsoft Azure, Okta, OneLogin, CAS a Shibboleth. Tato flexibilita umožňuje organizacím používat jejich aktuální adresářovou infrastrukturu pro Webex SSO s Duo MFA.

Duo funguje jako silná ověřovací vrstva nad autentizací primárního adresáře. Fungu je jako poskytovatel identity (IdP) pomocí SAML 2.0 k vynucení dvoufaktorového ověřování (2FA) před udělením přístupu k. Duo vyhodnocuje kontext uživatele, zařízení a sítě na základě konfigurovatelných zásad umožňujících nebo odepř ení přístupu, čímž zvyšuje zabezpečení nad rámec pouhého uživatelského jména a hesla. Duo také poskytuje flexibilní ovládací prvky zásad, například vyžadování MFA při každém přihlášení pro některé aplikace a méně často pro jiné.

Mezi výhody Cisco Duo patří:

Vylepšené zabezpečení: Přidává MFA odolnou proti phishingu, která chrání přístup a snižuje riziko ohrožených hesel.

Flexibilní zásady: Umožňuje podrobnou kontrolu nad požadavky na ověřování podle aplikace nebo skupiny uživatelů.

Integrace s existujícími adresáři: Podporuje místní služby AD, OpenLDAP, cloudové adresáře a různé poskytovatele SSO, čímž minimalizuje změny infrastruktury.

Uživatelské pohodlí: Podporuje jednotné přihlašování (SSO) ke snížení únavy heslem tím, že umožňuje uživatelům přihlásit se jednou a bezpečně přistupovat k více zdrojům.

Důvěryhodné koncové body: Podporuje důvěru zařízení pro klienty v systémech Windows a macOS, čímž zlepšuje stav zabezpečení.

Samoobslužná registrace: Inline registrace a dvojitá výzva zlepšují uživatelský komfort během nastavení MFA.

Duo MFA s SSO pro využívá k ověřování uživatelů existující adresáře, jako Active Directory je OpenLDAP nebo poskytovatele cloudových identit. Úlohou společnosti Duo je poskytovat silný druhý faktor autentizace založený na zásadách integrovaný prostřednictvím SAML 2.0, který zvyšuje bezpečnost při zachování uživatelského pohodlí prostřednictvím SSO. Mezi výhody patří lepší pozice zabezpečení, flexibilní pro sazování zásad, bezproblémová integrace a lepší uživatelský komfort.

Společnost Cisco doporučuje implementaci SSO pro uživatele. Pro lepší zabezpečení se doporučuje integrace s Cisco Duo.

Strategie Enterprise IAM a SSO by měla být nasazena před zahájením přechodu z na.

Vlastnosti

má plný doplněk základních funkcí, které jsou součástí služby. To zahrnuje mnoho funkcí volání na podnikové úrovni, které jsou k dispozici již mnoho let. Možná nevidíte 100% paritu mezi funkcemi a funkcemi, ale jak vidíte na obrázku níže, klíčové funkce volání jsou k dispozici v.

Webex Callingfunkce podnikové úrovně

Kromě mnoha uživatelských funkcí má základní systémové funkce, které jsou součástí platformy. Patří mezi ně funkce, jako jsou automatická obsluha, fronty hovorů, park volání atd. Všechny dostupné základní funkce systému můžete vidět v části Služba → Volání → Funkce, jak je znázorněno na obrázku Webex Callingzákladní funkce.

Webex Callingzákladní funkce

Automatická obsluha

Automatická obsluha umožňuje nepřetržitou automatizaci zpracování příchozích hovorů, což umožňuje efektivní zpracování hovorů bez nutnosti, aby osoba přijala každý hovor.

Automatická obsluha odpovídá na příchozí hovory a poskytuje volajícímu nabídku možností, kam chce směrovat svůj hovor. Může to být osoba, hlasová schránka nebo volací služba (např. Fronta volání). Vol ající pomocí číselné klávesnice svého telefonu zadá číslo z nabídky automatického telefonního ho voru.

Automatická obsluha podporuje následující klíčové funkce:

Obchodní a mimopracovní plány

Rozvrh prázdnin

Volba nabídky vytáčení, která nasměruje zákazníky tam, kam potřebují jít

Přizpůsobte pozdravy

Volba vytočit podle názvu

Možnosti přesměrování hovorů

Analýzy a reporty Control Hub.

Další informace naleznete v tématu S práva automatických telefonních hovorů.

Zavolejte Park

Call park dává uživatelům možnost snadno pozastavit hovor, aby jiný uživatel mohl snadno načíst, když je k dispozici, aby jej přijal. Uvolňuje také uživatele, který odpověděl na původní hovor, aby uskutečňoval nebo přijímal další hovory, zatímco je hovor zaparkovaný.

K dispozici jsou dva typy call parků:

Call park direct - umožňuje každému uživateli zaparkovat hovor na pobočku jiného uživatele nebo na rozšíření call parku, jak je definováno správcem

Skupina volání parku - umožňuje definované skupině uživatelů automaticky zaparkovat hovory proti dostupným cílům parku definovaným pro skupinu. Těmito cíli mohou být rozšíření členů skupiny nebo rozšíření call parku.

V závislosti na konfiguraci a typu parkování mohou uživatelé načítat hovory vytočením *88+><extension of parked call>, stisknutím klávesy linky přidružené k rozšíření parku volání nebo pomocí softwarové klávesy na svém IP telefonu.

Možnost odvolání je k dispozici pro vyvolání zaparkovaného hovoru po určité době uživateli, který hovor zaparkoval, nebo alternativnímu uživateli.

Další informace naleznete v tématu S práva parkování hovorů v Řídicím centru.

Vyzvednutí hovorů

Vyzvednutí hovorů umožňuje správci definovat skupinu uživatelů (členů), kteří mohou přijmout hovor na telefon jiného člena. To dává uživateli možnost přijímat hovory, když jsou jeho spoluhráči zaneprázdněni a nemohou přijmout příchozí hovor.

Uživatelé ve skupině musí být na stejném místě.

Uživatelé mohou k vyzvednutí hovoru použít buď stolní telefon, nebo svůj stolní telefon.

:

Podporuje vizuální a zvuková oznámení

Oznámení o příchozím hovoru

Vyzvednutí hovoru na základě faktu (vytáčení *98) nebo oznámení

Oznámení o vyzvednutí hovorů pro víceřádkové.

Stolní telefony:

Oznámení o příchozím hovoru

Zvukové zvonkohry a vizuální upozornění přes LED sluchátko. 6821 podporuje pouze zvukové zvonkohry

Pokud je typ oznámení vybrán v seznamu není žádný

Oznámení o vyzvednutí hovorů pouze pro primární linky.

Další informace naleznete v tématu Konfigurace skupiny pro vyzvednutí hovorů.

Fronta hovorů

zahrnuje fronty volání pouze hlasové jako součást svých základních funkcí a každý uživatel s licencí Professional může být součástí fronty hovorů, agent nebo supervizor. Tato funkce umožňuje uživatelům efektivně komunikovat se zákazníky. Fronty hovorů podporují podmnožinu některých základních funkcí call centra, jako jsou hlasové fronty, zpětné volání, směrování dovedností nebo priorit, správa front agentů, analytika, vytváření zpráv atd.

Výzva společnosti Cisco pro integraci Microsoft Teams umožňuje agentům přístup k hovorům a funkcím fronty volání přímo z jejich klienta Microsoft Teams.

Volací fronty podporují následující klíčové funkce:

Pozdravy a zprávy (uvítání, pohodlí, šepot atd.)

Držte hudbu

Zpětné volání

Zásady směrování fronty (noční služba, svátky, přeposílání)

Přihlášení/odhlášení do fronty agenta

Správa stavu fronty agentů

nebo podpora stolního telefonu

Dozorčí agent volá monitorovat, koupí, čluní nebo převezme kontrolu prostřednictvím přístupových kódů funkcí (FACS)

(přístup správce) pro:

správa fronty

Analýza a vykazování agentů a front

Správa fronty, agentů a supervizorů.

Další informace naleznete v tématu Konfigurace fronty hovorů.

má doplňkovou funkci Customer Assist, která poskytuje další funkce fronty hovorů a poskytuje agentům a supervizorům lepší uživatelský zážitek v rámci. Porovnání funkcí Fronty volání a Customer Assist najdete v tématu Porovnání Webex Callingfunkcí fronty hovorů a zákaznické podpory.

Huntská skupina

Hunt Groups umožňují směrování příchozích hovorů konkrétní skupině uživatelů prostřednictvím předem stanoveného vzoru směrování hovorů. Tím je zajištěno, že hovory jsou přijímány správnou skupinou uživatelů nebo odeslány do hlasové schránky k následnému sledování.

Jeden velký rozdíl mezi skupinami lovu a frontami volání spočívá v tom, že hovory nejsou ve frontě ve skupinách lovu, takže pokud nejsou k dispozici žádní uživatelé ve skupině Hunt, kteří by mohli přijmout hovor, bude odpojen, odeslán do hlasové schránky nebo přesměrován na jiné číslo (uživatel nebo služba).

Další informace naleznete v tématu S práva vyhledávacích skupin v Ří dicím centru.

Provozní režimy

Funkce provozních režimů umožňuje podnikům efektivně směrovat hovory do různých destinací (uživatelé, hlasová schránka, volací služby, jako je fronta hovorů). Místo a kdy je hovor směrován, je založeno na roz vrhu denní doby a dne v týdnu a každý uživatel může být oprávněn spravovat tyto režimy (plány) za účelem řízení změn směrování hovorů.

Například hovory do fronty volání mohou být směrovány do jiné fronty hovorů s agenty v jiném časovém pásmu, aby přijímali hovory mimo pracovní dobu, během pracovní doby směrovány k místním agentům, a během prázdnin mohou být směrovány do hlasové schránky pro následné sledování poté, co se agenti vrátí do kanceláře.

Autorizovaný uživatel může přepínat mezi těmito různými scénáři (režimy) přesměrování hovorů, pokud potřebuje změnit, kam jsou příchozí hovory směrovány po určitou dobu. Tito uživatelé mohou spravovat režimy prostřednictvím svých telefonů 6800/7800/8800 MPP, telefonů 9800 nebo v uživatelském centru na Manage modes.

Další informace naleznete v části Smě rování hovorů na základě provozních režimů v části Webex Calling.

Skupina stránkování

Stránkovací skupiny umožňují uživatelům uskutečnit jednosměrný hovor a odeslat zvukovou zprávu skupině uživatelů. Každá skupina může obsahovat až 75 cílových uživatelů a/nebo pracovních prostorů, na které se dostanete vytočením předdefinovaného čísla nebo rozšíření.

Když uživatel zavolá stránkovací skupinu, provede se simultánní hovor na všechny přiřazené cíle ve skupině, v tomto okamžiku může volající vyslovit své zprávy a zavěsit, jakmile jsou dokončeny.

Další informace naleznete v tématu Konfigurace stránkovací skupiny v Řídicím centru.

nahrávky

podporuje nahrávání hovorů uskutečněných nebo přijatých uživatelem. To může být vyžadováno pro potřeby kvality, zajištění, bezpečnosti nebo školení. Ve výchozím nastavení jsou hovory zaznamenávány, ale pokud jsou vyžadovány další funkce nahrávání nebo požadavky na dodržování předpisů, lze použít i jiné poskytovatele nahrávání třetích stran.

Při použití jako záznamové platformy jsou všechny nahrané hovory spravovány uvnitř. Plní správci s rolí Compliance Officer mohou nahrávat a stahovat nahrávky. Bez role Compliance Officer může správce smazat pouze nahrávky.

Další informace o této funkci a seznam nahrávání třetích stran naleznete v tématu S práva nahrávání hovorů pro Webex Calling.

Dosah jednoho čísla

Dosah jednoho čísla umožňuje volání na telefonní číslo uživatele pro vyzvánění více zařízení. To může zahrnovat další stolní telefony i mobilní telefony. Z těchto zařízení lze také uskutečňovat hovory a uživatelé mohou mezi nimi tlačit a vytáhnout hovory.

Další informace o této funkci a o tom, jak ji správce konfiguruje, naleznete v tématu Konfigurace dosahu jednoho čísla (kancelář kdekoli).

Další informace o tom, jak může uživatel spravovat a konfigurovat tuto funkci pro sebe v Webex User Hub (portálu), naleznete v tématu Konfigurace dosahu jednoho čísla (kancelář kdekoli).

Skupina hlasové schránky

Skupiny hlasové schránky umožňují sdílenou hlasovou schránku, kterou lze přiřadit uživateli nebo funkci směrování hovorů. Některé z důvodů, proč může být vyžadována skupina hlasové schránky, jsou:

Obecná hlasová schránka pro oddělení nebo pracovní skupinu

Přidání možnosti hlasové schránky do automatické obsluhy nebo skupiny lovu

Odesílání přepadových hovorů z fronty hovorů

Uživatelé, kteří potřebují pouze hlasovou schránku.

Další informace naleznete v tématu Správa sdílené hlasové schránky a příchozí faxové schránky pro. Webex Calling

Konzola obsluhy je uvedena na stránce Funkce volání ve Webexu, jedná se však o doplňkovou funkci, která vyžaduje zakoupení licence na konzoli doprovodu k použití.

Další informace naleznete v tématu Začínáme s konzolou Attendant Console.

Informace o všech funkcích, včetně některých doplňkových funkcí, najdete v tématu Funkce dostupné podle typu licence pro Webex Calling.

Tabulka 1. Informace, které je třeba zachytit pro každé místo
Informace	Komentář
Rozsah (y) rozšíření	Každé umístění může mít rozšíření začínající různými číslicemi. Jedna číslice musí být ušetřena pro číslici řízení mezi místy (například 8) a jedna pro číslici řízení PSTN (například 9). Žádný rozsah rozšíření nemůže začínat žádnou z těchto dvou číslic. Všechny rozsahy rozšíření všech umístění musí mít stejnou délku.
Rozsah (y) DID	-
Číslice řízení PSTN	-
Kód webu	Všechny kódy stránek všech míst musí být jedinečné a mít stejnou délku.
Hlavní číslo	Při vytváření umístění je třeba zřídit dva DID. Jedno jako hlavní číslo (například přiřazené službě automatické obsluhy) a jedno pro portál hlasové sch ránky. Zajistěte jeden DID pro číslo hlasové schránky.
Číslo hlasové schránky
Počet licencí	Požadované licence podle typu včetně Standard, Professional, Workspace, Route List, Outbound Calling Plan.
Souběžné hovory v rušné době	Součet souběžných hovorů mezi zařízeními a mezi zařízeními a místní bránou (PSTN a volání do zařízení). Potřebné k určení požadované šířky pásma přístupu k internetu.
Země	-
Časové pásmo	-
Jazyk	-
Kontakt (jméno, telefon, e-mail)	-
Adresa (ulice, město, stát, PSČ)	-
Fyzické odeslané umístění záchranných služeb pro koncové body	Místo odeslání zařízení používané pro tísňové volání obecně zahrnuje následující: adresa budovy, adresa budovy+číslo patra, adresa budovy+číslo apartmá nebo adresa budovy + číslo podlaží + číslo kanceláře/kubické číslo.
Jedinečné fyzické umístění v síti na zařízení pro tísňové služby	Fyzické umístění sítě pro tísňové volání obecně zahrnuje následující: přepínač/switchport pro kabelová zařízení, identifikátory základní sady služeb (AP) bezdrátového přístupového bodu (BSSID) pro bezdrátově připojená zařízení a/nebo místní podsítě IP pro koncová zařízení.

Tabulka 2. Příklad podnikového číslování
Stránky	Rozšiřující rozsah	Kód webu	Řada Enterprise
NYC	2XXX	202	8 202 2XXX
SFO	3XXX	203	8 203 3XXX
RTP	2XXX	204	8 204 2XXX

Tabulka 3. Rozsahy prodloužení pevných délek
Stránky	Rozšiřující rozsah	Rozšíření	Kód webu	Řada Enterprise
NYC	2XXX	2XXX	202	8 202 2XXX
SFO	8XXX	7XXX	203	8 203 7XXX
RTP	1XX	11XX	204	8 204 11XX

Tabulka 4. Přechod sedmimístné volby

Stránky	Rozšíření	Kód webu	Řada Enterprise	Stránka óda	Enterprise Angle
NYC	2XXX	22	8 22 2XXX	822	8 822 2XXX
SFO	8XXX	23	8 23 7XXX	823	8 823 7XXX
RTP	1XXX	24	8 24 11XX	824	8 824 11XX

Tabulka 5. Možnosti zřizování uživatelů - souhrn
Metoda přiřazení	Klady	Nevýhody
Manuální přes	Jednoduché pro několik uživatelů. Umožňuje přesnou a podrobnou kontrolu nad přiřaz ením licencí.	Není škálovatelný, časově náročný Při ručním zadávání je náchylný k lidské chy bě.
Automatické šablony licencí	Škálovatelný Snižuje manuální chyby Lze použít pro nové i stávající uživatele.	Vyžaduje platná telefonní čísla a místa. Složitější nastavení Vyžaduje také skupiny uživatelů na skupinu uživatelů s ekvivalentními licenčními požadavky.
Hromadné nahrávání CSV	Efektivní pro velké uživatelské sady Umožňuje současné přiřazování licencí, telefonních čísel a rozšíření.	Vyžaduje pečlivé formátování CSV Potenciál chyb, pokud telefonní čísla nebo přípony chybí nebo jsou nesprávné.
Přiřazení na základě rozhraní API	Automatizovatelný, flexibilní. Umožňuje současné přiřazování licencí, telefonních čísel a rozšíření.	Vyžaduje vývoj a znalosti API.

Tabulka 6. Možnosti zřizování uživatelů pro
Způsob poskytování	Popis	Klady	Nevýhody
Manuál	Vytvářet/spravujte uživatele jednotlivě v	Jednoduché pro několik uživatelů; není potřeba žádná infrastruktura	Není škálovatelný; časově náročné pro mnoho uživatelů
Hromadné (soubor CSV)	Importujte/aktualizujte uživatele hromadně prostřednictvím CSV	Efektivní pro skupiny; není nutné kódování	Manuální příprava CSV; méně dynamické
Lidé a SCIM 2.0 API	Programová správa uživatelů prostřednictvím rozhraní API Webex	Flexibilní; podporuje automatizaci a integraci	Vyžaduje rozvoj a infrastrukturu
Synchronizace adresářů	Automatická synchronizace z aplikací AD, Entra ID, SCIM, Unified CM	Automatizuje životní cyklus; podporuje filtrování a mapování	Složitost nastavení: některé možnosti mají omezené funkce nebo vyžadují infrastrukturu

Tabulka 7. Možnosti správy skupin a členství ve skupině
Varianta	Popis	Klady	Nevýhody
přidělování skupin (skupiny)	Vytvářejte a spravujte skupiny přímo v. Přidávání/odebrání členů ručně nebo prostřednictvím CSV.	Plná kontrola nad členstvím ve skupině Okamžitá aplikace licencí a šablon Snadné vytváření a úpravy skupin	Vyžaduje se ruční aktualizace Riziko chyb při ručním nahrávání CSV Žádná automatická synchronizace s externími adresáři
Synchronizované skupiny z Entra ID (Azure AD) nebo Active Directory	Automaticky synchronizujte skupiny zabezpečení a členství z externích adresářových služeb.	Automatizovaná synchronizace snižuje manuální práci Zajišťuje konzistenci s podnikovým adresářem Podporuje velké organizace	Nelze upravit členství ve skupině Zpoždění synchronizace až 12 hodin Vnořené skupiny vyžadují ruční výběr
Skupiny a SCIM 2.0 API (Skupiny)	Použijte skupiny nebo rozhraní SCIM 2.0 API pro programovou správu skupin a členství	Automatizace a integrace s jinými systémy Škálovatelné pro velká nebo složitá prostředí	Vyžaduje vývojové úsilí Složitost závisí na použití API

Implementovat

Připravenost k síti

Počáteční nastavení

Ověření domény

Prohlášení (převod) existujících uživatelů

Konfigurace a testování synchronizace adresářů

Nastavení a testování jednotného přihlašování (SSO)

Pořízení, poskytování a ověřování licencí

Webex Callingnastavení služby

Pilotní migrace

Zakoupit PSTN

Konfigurace umístění

Integrace s místním řízením hovorů

Migrace uživatelů v dávkách

Pracovní prostory

Zajišťovací zařízení

Konfigurace funkcí

Přijímací zkoušky

Připravenost k síti

Prvním krokem při přechodu na je zajištění spolehlivého a bezpečného připojení k internetu mezi místní sítí a cloudem.

Vzhledem k tomu, že většina organizací se připojuje k internetu prostřednictvím jednoho nebo více firewall ů nebo bezpečnostních zařízení, je nezbytné ověřit, zda jsou podporovány požadované toky provozu.

Správci sítě a zabezpečení musí těmto tokům rozumět z hlediska:

Směr (příchozí vs. odchozí)

Protokoly (Příklad - SIP TLS, SRTP, HTTPS)

Roz@@ sahy IP adres používané službami

Čísla port ů, která musí být otevřena nebo povolena.

Tím je zajištěno, že firemní firewally, zařízení NAT a další síťová infrastruktura jsou správně nakonfigurovány tak, aby vyhovovaly provozu při zachování podnikových zásad zabezpečení.

Informace o požadovaných tocích včetně adresy IP, portů a protokolů naleznete v části Referenční informace o portu pro Webex Calling. Tyto informace slouží ke konfiguraci brány firewall, proxy serverů a další síťové infrastruktury ve stávajícím nasazení pro povolení síťových toků.

Decentralizovaný internetový únik z každé pobočky nebo webu je doporučeným přístupem pro služby cloudové spolupráce, jako je. Umožněním místního ukončení provozu tento model:

Snižuje zpáteční zpoždění a chvění a zlepšuje celkovou kvalitu hovoru

Efektivně se škáluje, protože více uživatelů a webů přechází na

Bezproblémově pracuje s SD-WAN, která dokáže dynamicky směrovat relace k nejbližšímu vstupnímu bodu cloudu pro optimální výkon

Umožňuje sledovat polohu uživatele na základě jejich veřejné IP adresy, což pomáhá s analýzou cesty médií a odstraňováním problémů.

Kromě toho musí organizace zajistit dostatečnou šířku pásma internetu na každém místě. Šíř ka pásma by měla být dimenzována na základě očekávaného počtu souběžných hovorů, vybraného kodeku (např. Opus nebo G.711) plus režijních nákladů na signalizaci, opětovné vysílání a růst. To je v souladu s přípravnou fází životního cyklu PPDIO a vytváří pevný základ pro migraci.

Počáteční nastavení

Pododdíl počátečního nastavení ve fázi implementace nasazení je základem pro vytvoření dobře strukturovaného a spravovatelného prostředí cloudových volání. Tato fáze zahrnuje kritické úkoly, jako je nastavení organizace, získávání a přiřazování licencí a ověření a nárokování domén vaší společnosti, aby byla zajištěna správná správa a zabezpečení uživatelů. Kromě toho zahrnuje zřizování licenčních šablon pro automatizaci přiřazování uživatelských licencí, konfiguraci jednotného přihlašování (SSO) pro zjednodušení ověřování uživatelů a zvýšení zabezpečení a úpravu nastavení služeb a klienta tak, aby odpovídaly organizačním zásadám a potřebám uživatelů. Dokončení těchto činností počátečního nastavení zajišťuje, že prostředí je správně nakonfigurováno pro škálovatelnost, zabezpečení a bezproblémové uživatelské prostředí, což připravuje půdu pro následné nasazení a provozní fáze.

Ověření domény

Aby bylo možné identifikovat uživatele registrované na e-mailových doménách vaší společnosti, je nezbytné ověřit vaše domény. Bez ověření domény budou uživatelé přiřazeni spotřebitelské organizaci, což komplikuje správu uživatelů pro vaši společnost. Ověření domény je povinný krok, který umožňuje vaší organizaci požadovat a efektivně spravovat tyto uživatele.

Ujistěte se, že jsou ověřeny všechny domény přidružené k e-mailovým adresám vašich uživatelů. Ově ření domény není exkluzivní; stejnou doménu lze ověřit ve více organizacích.

Další informace o správě domén naleznete v tématu Správa domén.

Prohlášení (převod) existujících uživatelů

Po úspěšném ověření domén můžete pokračovat v nárokování uživatelů, kteří se zaregistrovali k používání e-mailových domén vaší společnosti ve vaší organizaci. Tento proces konsoliduje všechny uživatele pod jeden organizační deštník, což umožňuje centralizovanou správu a zjednodušenou správu. Nárokováním těchto uživatelů zajistíte, že vaše společnost má plnou kontrolu nad uživatelskými účty, což vám umožní přiřadit příslušné licence, konfigurovat služby a efektivně poskytovat potřebnou podporu. Tento přístup jednot né správy zvyšuje zabezpečení, zjednodušuje zřizování uživatelů a zajišťuje konzistentní přístup ke službám v celé organizaci. Tvrzení uživatelů také brání jejich správě v externích nebo spotřebitelských organizacích, čímž zachovává organizační integritu a kontrolu nad zdroji spolupráce.

Další informace o nárokování uživatelů naleznete v tématu Prohlášení uživatelů vaší organizaci (převod) uživatelů.

Konfigurace a testování synchronizace adresářů

Chcete-li umožnit bezproblémovou správu uživatelů a skupin, můžete synchronizovat uživatele a skupiny z podnikového adresáře buď Microsoft Entra ID (dříve Azure AD) nebo Microsoft Active Directory (AD). Tento proces zajišťuje, že identity uživatelů a členství ve skupinách jsou konzistentně udržovány ve vašem prostředí.

Pro organizace, které implementují postupné nasazení, je zásadní kontrolovat a omezit rozsah synchronizace během počátečního zavádění. To minimalizuje riziko nezamýšlených změn a umožňuje cílené testování před širším přijetím.

Nejúčinnější metodou filtrování synchronizovaných uživatelů je využití členství ve skupině adresářů:

1
Vytvoření vyhrazené synchronizační skupiny: Ve svém podnik ovém adresáři (Microsoft Entra ID nebo AD) vytvořte skupinu zabezpečení speciálně pro synchronizaci (například synchronizační skupinu).

2
Naplnění skupiny cílovými uživateli: Do této skupiny přidejte pouze uživatele, které chcete synchronizovat (například testovací skupinu během pilotní fáze). To vám umožní pevně řídit, kdo je součástí procesu synchronizace.

3
Konfigurace synchronizační smlouvy s filtrováním založeným na skupinách: Při nastavování dohody o synchronizaci v zřizování Directory Connector nebo Entra ID nakonfigurujte rozsah tak, aby zahrnoval pouze uživatele, kteří jsou členy určené skupiny.

Pro Microsoft Entra ID můžete v nastavení zřizování použít přiřazení založená na skupinách

Pro službu AD můžete definovat filtr LDAP tak, aby zahrnoval pouze uživatele patřící do určené skupiny.

4
Rozbalte skupinu podle potřeby: Jak postupujete do širších fází nasazení, jednoduše přidejte do synchronizační skupiny další uživatele nebo skupiny. Rozsah synchronizace se automaticky rozšíří tak, aby zahrnoval tyto uživatele, což umožní řízené a postupné zavádění.

Příklad implementačních kroků:

V aktivním adresáři:

Vytvořte skupinu zabezpečení s názvem synchronizační skupina.

Přidejte požadované pilotní uživatele do této skupiny.

Nastavte Directory Connector pomocí filtru LDAP, například: (memberOF=CN=WebEx Sync Group, OU = Groups, DC=YourDomain, DC=COM).

Do Microsoftu zadejte ID:

Vytvoření skupiny s názvem synchronizační skupina

Přiřaďte skupinu k nastavení zřizování v Entra ID

Budou zřízeni pouze uživatelé v této skupině.

Před aplikací na celou organizaci vždy otestujte synchronizaci založenou na skupinách v neprodukčním prostředí

Pravidelně kontrolujte členství ve skupině, abyste zajistili synchronizaci pouze oprávněných uživatelů

Pro průběžnou správu automatizujte aktualizace členství ve skupině na základě obchodních pravidel nebo HR systémů, pokud je to možné.

Odkazy:

Synchronizace uživatelů Entra ID do Control Hub

Nastavení aplikace Entra ID Wizard v Control Hubu

Adresářový konektor

Nastavení a testování jednotného přihlašování (SSO)

Jednotné přihlašování (SSO) zvyšuje zabezpečení a zjednodušuje přístup uživatelů tím, že umožňuje uživatelům ověřit se jednou pomocí svých fire mních přihlašovacích údajů a získat bezproblémový přístup k nim. podporuje integraci SSO s IDP vyhovujícími SAML 2.0, včetně Microsoft Entra ID (dříve Azure AD), federovaných řešení Active Directory (AD) a různých IDP třetích stran.

V tomto okamžiku by mělo být implementováno a testováno navržené nastavení SSO.

Odkazy:

Integrace jednotného přihlášení do řídicího centra

nakonfigurovat jednotné přihlášení pro správu webex

Konfigurace jednotného přihlášení pomocí Microsoft Entra ID

SSO s více IDP

Správa jednotného přihlášení při integraci v Control Hub

Pořízení, poskytování a ověřování licencí

V rámci počátečního nastavení pro, je nezbytné pořídit, poskytnout, a ověřit příslušné licence pro efektivní umožnění a správu služeb. Proces nákupu zahrnuje výběr typů licencí na základě uživatelských rolí a úloh, jako jsou licence Professional, Standard a Workspace. Licence jsou generovány a poskytovány prostřednictvím softwarových platforem společnosti Cisco nebo prostřednictvím partnerů. Po zadávání zakázek a poskytování, je třeba ověřit správné počty licencí. Tento proces zajišťuje, že organizace má aktivované správné licence a připravené k použití při nasazení.

V rámci počátečního nastavení licencí v, je důležité nakonfigurovat automatické licencování založené na organizaci, aby se zjednodušilo přiřazování licencí novým uživatelům. Toto nastavení umožňuje automatické udělování licencí při přidávání uživatelů do organizace, což eliminuje potřebu ručního přiřazování licencí. Při konfiguraci automatického licencování na úrovni organizace vyberete služby, které chcete přiřadit, a definovat rozsah, například použití licencí pouze pro budoucí uživatele nebo zahrnutí stávajících uživatelů.

Pokud však plán nasazení zahrnuje použití automatického licencování na úrovni skupiny, můžete se rozhodnout nepřiřadit licence na úrovni organizace, abyste předešli konfliktům nebo duplicitnímu přiřaz ení licencí. Při automatickém licencování na úrovni skupiny jsou licence přiřazovány na základě členství ve skupině. Uživatelé ve více skupinách obdrží licence ze všech příslušných přiřazení skupin.

Konfigurace přiřazení licencí založená na skupině musí být provedena po dokončení synchronizace adresářů, aby existovaly synchronizované skupiny a mohly být použity pro přiřazení licencí.

Konkrétně automatické přiřazení licence vyžaduje další podrobnosti o zřizování, jako je umístění uživatele a přiřazení telefonního čísla. Pracovní telefonní číslo uživatele musí být ve formátu +E.164, předem zřízené a přiřazené platnému umístění, aby mohla být licence automaticky aktivována. Pokud tyto podmínky nejsou splněny, nebudou uživateli poskytovány služby automaticky a může vyžadovat ruční zásah.

Stručně řečeno, nakonfigurujte automatické licencování založené na organizaci pro nové uživatele, pokud chcete široké přiřazení licencí pro celou organizaci. Pokud dáváte přednost podrobnějšímu řízení nebo máte různé licenční potřeby pro každou skupinu, nakonfigurujte automatické licencování na úrovni skupiny a vyhněte se přiřazování licencí na úrovni organizace, abyste zabránili překrývání a zajistili řádnou správu licencí.

Webex Callingnastavení služby

Je nezbytné provést komplexní kontrolu a konfiguraci nastavení globálních služeb uvnitř.

Začněte přístupem do sekce nastavení a přechodem do části nastavení. Pečlivě prozkoumejte každou konfigurovatelnou možnost, mimo jiné včetně konfigurace interního vytáčení, parametrů tísňového volání, zá sad směrování hovorů, správy hlasové schránky a výchozího nastavení zařízení.

Upravte tato globální nastavení tak, aby odrážela zásady a rozhodnutí o návrhu vaší organizace.

Taky, nastavení nastavení a šablony uživatelů a aplikací.

Pilotní migrace

Během fáze implementace, provedení pilotní migrace představuje kritický milník při ověřování přechodu z na. Tento pilotní projekt zahrnuje zřízení reprezentativní podskupiny uživatelů v jednom nebo více lokalitách na platformě, což zajišťuje, že vybraná populace odráží různé případy použití a organizační role. Souběžně s migrací uživatelů musí být základní služby spolupráce včetně hlasové schránky, automatických telefonních hovorů, front volání a vyhledávací skupiny převedeny na jejich ekvivalenty, aby byla zacho vána kontinuita provozu a funkčnost služeb.

Pilotní migrace by měla využívat stejnou kombinaci nástrojů poskytovaných společností Cisco a nástrojů pro migraci třetích stran, které jsou plánovány pro širší organizační nasazení, a zajistit, aby procesy, pracovní postupy automatizace a integrační body byly důkladně ověřeny za reprezentativních podmínek.

Primární cíle tohoto pilotního nasazení jsou dvojí: za prvé, ověřit a zdokonalit procesy přechodu typu end-to-end, včetně pracovních postupů zřizování uživatelů, postupů migrace dat a konfigurace koncových bodů; a za druhé, komplexní ověření funkčnosti migrovaných služeb za provozních podmínek reálného světa.

Tento postupný přístup umožňuje projektovému týmu identifikovat a napravit jakékoli technické nebo procedurální problémy v kontrolovaném prostředí, shromažďovat zpětnou vazbu uživatelů o nové platformě, posoudit účinnost vybraných migra čních nástrojů a získat důvěru v metodiku migrace před pokračováním v širším organizačním nasazení.

Zjištění získané během této pilotní fáze jsou nápomocné při optimalizaci následných migračních vln a zajištění plynulého přecho du s minimalizací rizik pro celý podnik.

Zakoupit PSTN

Chcete-li získat služby PSTN pro, nejprve vyberte možnost připojení PSTN v.

Pokud organizace plánuje dočasně nebo neomez eně udržovat hybridní řízení duálních hovorů (fáze 1 na obrázku Fázovaný přechod volání: hybridní a clou dové), bude muset nasadit jednu nebo více místních bran pro místní PSTN, aby bylo možné volání mezi koncovými body a koncovými body nasadit jednu nebo více místních bran .

Pokud je konečným cílem úplný přechod (fáze 2) do cloudu včetně PSTN, bude pro PSTN vyžadován buď plán volání Cisco nebo možnost Cloud Connect for.

Spolupracujte s vybraným poskytovatelem na objednání a portu telefonních čísel před jejich konfigurací. Objednávání telefonních čísel nebo iniciování objednávek portů je vyžadováno/možné pouze pro místní PSTN a Cloud Connect pro. U tarifů volání společnosti Cisco je objednávání a portování zahájeno z Control Hub, jakmile je místo vytvořeno, a v zemích, kde je k dispozici plán volání Cisco. Další informace o plánech Cisco Calling najdete v tématu Začí náme s plány Cisco.

V rámci implementace PSTN se ujistěte, že váš poskytovatel povolil příchozí i odchozí služby PSTN pro vaši polohu. Kromě toho proveďte testovací hovory a ověřte, zda jsou hovory směrovány správně přes zvolené připojení PSTN.

Konfigurace umístění

Před přidáním uživatelů a zařízení je nutné zřídit místa volání. Pro každé místo musí být zadána platná adresa ulice. V USA a Kanadě je tato adresa ověřena a používána platformou k odesílání informací o poloze PIDF-LO pro tísňová volání.

Při konfiguraci umístění, která používají místní síť PSTN, je třeba odpovídajícím způsobem nastavit místní brány. V aplikaci musí být vytvořen kmen a skupina tras pro každou místní bránu a skupina tras je poté přiřazena jako volba PSTN pro umístění. Společnost Cisco důrazně doporučuje vždy zvolit skupinu tras jako volbu PSTN, protože tento přístup umožňuje v budoucnu snadno přidat další kmeny, což podporuje škálovatelnost i redundanci. Společnost Cisco také doporučuje povolit podporu duální identity a P-Charge-Info na každém kmeni PSTN, protože to zjednodušuje identifikaci fakturovatelné strany pro odchozí přímé nebo přesměrované hovory. Pokud váš poskytovatel služby PSTN používá pro fakturaci jinou hlavičku, můžete zkopírovat informace z hlavičky P-Charge-Info na místní bráně do požadované hlavičky fakturace.

Pro místa, která používají Cloud Connect pro nebo Cisco Calling Plan jako možnost PSTN, jednoduše vyberte příslušnou volbu PSTN pro umístění během nastavení. Pokud umístění používá buď Cloud Connect pro nebo místní PSTN, budete muset přidat telefonní čísla, která byla objednána v předchozím kroku. Čísla lze přidat jako neaktivní, pokud nechcete, aby byla okamžitě zahrnuta do směrování hovorů; tato čísla můžete aktivovat později, když jsou přiřazena uživatelům nebo funkcím.

Je důležité vždy nastavit hlavní číslo pro každé místo. Hlavní číslo lze přiřadit uživateli nebo funkci, například automatickému obsluze. Chcete-li povolit hlasovou schránku v daném místě, nezapomeňte nastavit číslo pilota hlas ové schránky, známé také jako číslo hlasového portálu.

Mezi další nastavení pro místa volání patří konfigurace podrobností tísň ového volání, jako je číslo zpětného volání tísňového volání, možnosti oznámení a vylepšené funkce tísňového volání. Měli byste také zkontrolovat a upravit nastavení nahrávání, jazykové předvolby a konfigurace zařízení podle potřeby pro každé umístění. Pokud vaše organizace používá zkrácenou interní internetovou volbu s podnikovými významnými čísly, nezapomeňte nakonfigurovat jedinečný kód lokality pro danou lokalitu v nastavení interního vytáčení . A konečně, pokud externí vytáčení vyžaduje číslici odchozího vytáčení, nezapomeňte ji nastavit v nastavení externího vyt áčení. Pokud je nakonfigurována číslice odchozího vytáčení, společnost Cisco doporučuje povolit vynucování odchozích číslic vytáčení, aby byla zajištěna konzistence.

Integrace s místním řízením hovorů

Pro integraci s místním řízením hovorů je nutné nakonfigurovat kmeny, skupiny tras, podnikové vytáčecí plány a umístění i globální nastavení. Začněte nastavením kmenů a místních bran určených pro propojení s místním systémem řízení hovorů; tento krok je vyžadován pouze v případě, že jsou nutné vyhrazené kmeny. Pokud jsou stávající kmeny a skupiny tras dostatečné pro vaše nasazení, lze je znovu použít pro místní propojení bez další konfigurace.

Jakmile jsou vytvořeny kmeny a skupiny tras, pokračujte v vytváření podnikových vytáčecích plánů a přiřaďte příslušnou skupinu tras jako cíl pro každý vytáčecí plán. Pokud integrace zahrnuje více místních systémů řízení hovorů připojených prostřednictvím různých kmenů, bude vyžad ováno více telefonních plánů. Je důležité zajistit, aby tyto vytáčecí plány obsahovaly pouze vzory nezbytné pro směrování ho vorů do místních cílů.

Pokud vaše nasazení vyžaduje podporu pro neznámé směrování rozšíření, měla by být tato funkce povolena na úrovni umístění. Pokud je navíc aktivováno směrování neznámého rozšíření, musíte zadat maximální délku neznámého rozšíření v části Smě rování hovorů mezi místy a místy nastavení volacích služeb v. Tím je zajištěno bezproblémové směrování hovorů a správné zpracování scénářů vytáčení na základě rozšíření ve vašem integrovaném prostředí.

Migrace uživatelů v dávkách

Když migrujete uživatele z na, možná nebudete moci přesunout všechny uživatele současně. To může být způsobeno několika důvody, mimo jiné včetně počtu webů nebo uživatelů, doby trvání přechodu na web a/nebo skupinu uživatelů najednou, omezeného IT nebo webového zdroje pro podporu okna změny, trvání okna změny, složitosti změny atd.

Při migraci uživatelů ve fázích je důležité určit, kteří uživatelé musí migrovat společně ve stejné dáv ce. Primárním cílem je společně migrovat uživatele, kteří mají vzájemnou závislost na svých volacích službách a funkcích. Chcete zajistit, aby všechny jejich funkce volání (Příklad - Fronty volání) byly plně funkční stejně jako před zapnutím přechodu.

I když implementujete propojení volání mezi místními bránami a s nimi, nelze sdílet sdílené služby nebo funkce napříč tímto připojením. Proto je třeba identifikovat závislosti mezi uživateli tím, že se podíváte na funkce, jako jsou:

Monitorování ostatních uživatelů pomocí BLF

Ve stejném loveckém pilotu, frontě volání atd

Sdílené řádky

Použití vyzvednutí hovorů

Používání stejných čísel parkovacích míst

Interkom

Vedoucí pracovník/administrátor.

Příkladem může být uživatel, který je součástí skupiny Hunt, na kterou se přechází. Tento uživatel přejde do skupiny Hunt Group a se všemi ostatními členy skupiny Hunt Group. Proto, po přechodu mohou Hunt Group a její členové úspěšně odpovídat na hovory na nové platformě.

To se stává náročnějším, když jsou uživatelé připojeni k různým skupinám uživatelů pro různé služby a funkce volání. To bude vyžadovat přechod více než jedné skupiny uživatelů a jedné volací služby současně.

Pomocí výstupu z nástroje Migration Insights nebo nástroje třetí strany, který jste použili ve fázi přípravy, určete, kteří uživatelé a funkce mají být seskupeny dohromady. Tento výstup by měl být použit k vytvoření plánu migrace a poskytne vám přehled o tom, jak seskupíte uživatele a funkce, které potřebují provést přechod společně.

Klíčové kroky při přechodu dávky uživatelů jsou:

Identifikace uživatelů pro společnou migraci

Ověřte, zda jsou všichni uživatelé v

Ověřte, že všechny TN pro uživatele existují

Ověřte správný formát telefonního čísla v adresáři

Zkontrolujte, zda jsou šablony licencí a nastavení pro skupiny uživatelů správně nastaveny

Ověření nebo konfigurace všech volacích služeb a funkcí pro skupinu uživatelů (před nebo během přechodu podle potřeby)

Ve firemním adresáři přidejte uživatele do skupiny uživatelů povolených volání

Využití nástrojů - nástroje pro migraci uživatelů a funkcí a/nebo nástroje třetích stran

Po přechodu zakázat/odstranit číslo adresáře uživatele/zařízení a volat funkce/služby.

Po migraci skupiny uživatelů otestujte podmnožinu uživatelů, abyste ověřili, že všechny jejich funkce a služby pro volání fungují správně. Pokud jsou funkce volání, jako je fronta volání, skupiny hledání atd., přecházeny se skupinou uživatelů, otestujte tyto volací služby, zda jsou správné funkce.

Pracovní prostory

V aplikaci se pracovní prostor týká sdíleného umístění (jako je konferenční místnost, místnost pro schůze nebo pracovní stůl), kterému lze přiřadit zařízení, rozšíření a uživatelé. Na rozdíl od tradičních telefonů Unifed CM jsou pracovní prostory:

Zaměřeno na polohu: vázáno na fyzické prostory.

Flexibilní pro zařízení: může mít jedno nebo více zařízení (stolní telefony, desky atd.).

Jakmile jsou pracovní prostory identifikovány jako součást přechodu na, lze je přidat do části Zařízení. Každý pracovní prostor potřebuje přiřazení zařízení, a pokud je již v němUnified CM, je třeba je resetovat nebo znovu zřídit. funkce, jako je hlasová schránka, přesměrování hovorů a vyzvednutí hovorů, lze povolit nebo zakázat a zásady lze podle potřeby použít pro videohovory, parkování hovorů a mobilitu. Otestu jte každý pracovní prostor interními a externími hovory, testováním funkcí videa, konferencí a mobility . Nakonec dejte uživatelům vědět o všech použitelných procesech pro zařízení pracovního prostoru a rezervace.

Další informace o pracovních prostorách v aplikaci naleznete v části Pracovní prostory.

Zajišťovací zařízení

Telefony, na které jsou aktuálně registrovány, budou muset být migrovány jako součást přechodu do cloudu. Aby byla migrace co nejjednodušší s minimální pravděpodobností selhání, doporučuje společnost Cisco migrovat fyzické weby nebo oddělení současně. Může však být vyžadováno migrace uživatelů v dávkách kvůli závislostem funkcí. Další podrobnosti naleznete v části Migrace uživatelů v dávkách.

Všechny podporované telefony, ze kterých potřebujete přejít, budou muset být nakonfigurovány jako uživatel nebo pracovní prostor a fyzický telefon bude muset být znovu nakonfigurován, aby se mohl zaregistrovat . Kromě toho telefony řady 7800 a 8800 potřebují upgrade firmwaru z firmwaru Enterprise na firmware Multiplatform Phone (MPP). Tento proces zahrnuje načtení přechodného firmwaru před načtením firmwaru MPP požadovaného pro registraci. Vyžaduje také příslušnou migrační licenci. Společnost Cisco tento proces v posledních několika letech vylepšila, aby vám usnadnila upgrade vašich telefonů s firmwarem Enterprise na firmware MPP. Další informace o krocích k dokončení upgradu firmwaru naleznete v tématu Převod IP telefonů Cisco řady 7800 a 8800 mezi firmwarem Enterprise a firmwarem MP P.

Kromě kroků uvedených v tomto článku obsahuje vestavěný nástroj Migrace telefonu doWebex Calling, který můžete použít k migr aci telefonů 7800 a 8800 z firmwaru Enterprise na MPP. Tento nástroj také umožňuje přidávat telefony a přiřadit je příslušným uživatelům nebo pracovním prostorům. Další informace o používání nástroje naleznete v tématu Migrace telefonu.

Pro všechny telefony řady 9800 registrované s výše uvedeným požadavkem na migraci firmwaru neplatí. Tyto telefony běží na PhoneOS, který je podporován oběma i. Chcete-li tyto telefony převést na, budete je muset přidatWebex Calling, přiřadit je uživateli nebo pracovnímu prostoru a poté obnovit tovární nastavení telefonů. Pořadí spouštění PhoneOS pro registraci níže ukazuje spouštěcí sekvenci PhoneOS a způsob, jakým se telefon zaregistruje, jakmile bude přidán, i když je telefon stále zřízený a/nebo jsou používány možnosti DHCP (Příklad - 150).

Zaváděcí sekvence PhoneOS pro registraci

podporuje tovární resetování zařízení PhoneOS, aby bylo možné Zero-Touch onboarding. administrátoři mohou vzdáleně obnovit tovární nastavení telefonů 9800 a 8875 prostřednictvím stránek správy CUCM, což eliminuje potřebu fyzického přístupu k telefonům pro zabudování telefonů. Tato funkce je podporována v balíčcích zařízení od 9. září 2025:

CUCM v15 — Unified Communications Manager verze 15

CUCM v14 - Unified Communications Manager verze 14.

Další informace o procesu registrace pro řadu 9800 naleznete v části Proces registrace.

Kromě telefonů Cisco IP může být vyžadováno poskytování dalších zařízení, jako jsou analogové telefonní adaptéry (ATA), bezdrátové telefony (Wifi, DECT), video zařízení, hlasové brány a ^zařízení a telefony třetích stran. Mnoho z těchto zařízení nemá cestu upgrad u firmwaru, jako jsou telefony IP, aby je mohli převést z podnikového firmwaru na cloudový firmware. Proto každé z těchto zařízení zajistíte v Control Hub. Na některé z nich nelze převést a ekvivalentní model je bude muset nahradit (např. ATA 191/192) a další budou vyžadovat ruční rekonfiguraci a/nebo změny softwaru.

Hlasové brány — Informace o migraci místní brány naleznete v tématu Migrace místní brány.
Další informace o konfiguraci hlasové brány VG400, VG410 nebo VG420 v Řídicím centru naleznete v tématu Místní brána

Analogový telefonní adaptér (ATA) - Chcete-li začít s Cisco ATA 191 a 192, přečtěte si Cisco ATA.

Bezdrátový telefon s Wi-Fi — Chcete-li integrovat bezdrátový telefon 840 a 860, přečtěte si článek Integrace bezdrátového telefonu Webex.

Bezdrátové telefony DECT - Chcete-li začít s novou řadou Cisco IP DECT 6800, podívejte se na Cisco IP DECT.

Postup vytváření a správy digitální sítě DECT v Řídicím centru naleznete v tématu Správa sítě DEC T

Další informace o Cisco IP DECT 6800 naleznete v příručce k nasazení

Zařízení a ^telefony třetích stran - Spolu pracujte s dodavateli ^třetích stran na požadavcích na zařízení/telefon a na procesu jejich migrace nebo nahrazení pro podporu.

Konfigurace funkcí

Všechny funkce volání, které jsou vyžadovány, musí být zřízeny před přechodem nebo během přechodu. Jak bylo popsáno v části Migrace uživatelů v dávkách, funkce volání musí být nakonfigurovány a převedeny při přechodu uživatelů, kteří je používají.

Podrobnosti o tom, jak konfigurovat jednotlivé funkce, naleznete v odpovídajících článcích nápovědy ke konfiguraci.

Automatické obsluhy — Chcete-li spravovat automatické obsluhy, přečtěte si článek Automatické obsluhy

Call park - Informace o správě parkování volání naleznete v části Park volání

Vyzvednutí hovorů — Chcete-li nakonfigurovat skupinu vyzvednutí hovorů, přečtěte si článek Vy zved nutí hovorů

Fronty volání — Postup konfigurace fronty hovorů naleznete v tématu Fronta volání

Lovecké skupiny — Informace o správě loveckých skupin naleznete v tématu S práva lovecké skupiny

Provozní režimy — Informace o směrování hovorů na základě provozních režimů viz Smě rování hovorů na základě provozních režimů

Stránkovací skupiny — Postup konfigurace stránkovací skupiny naleznete v tématu Konfigurace stránkovací skupiny

Záznamy - Informace o správě nahrávání hovorů naleznete v části S práva nahrávek

Dosah jednoho čísla — Chcete-li konfigurovat dosah jednoho čísla (kdekoli v kanceláři), přečtěte si článek Konfigurace jednoho čísla

Skupina hlasové schránky — Informace o správě sdílené hlasové schránky a příchozích faxů naleznete v tématu Správa hlasové schránky.

Přijímací zkoušky

Přijímací testování zajišťuje, že migrované prostředí splňuje funkční požadavky, funguje podle očekávání a poskytuje bezproblé mové uživatelské prostředí napříč všemi komunikačními pracovními postupy. Tento proces ověřování je mnohostranný a pokrývá vše od zřizování uživatelů a přiřaz ení čísel až po provozní výkon pokročilých funkcí volání .

Tato část poskytuje příklady a zdůrazňuje klíčové aspekty, které je třeba vzít v úvahu během akceptačního testování; nicméně, nemá sloužit jako vyčerpávající nebo komplexní kontrolní seznam.

Zřizování uživatelů a přiřazení čísel

Základním aspektem akceptačního testování je ověření, že všichni uživatelé jsou přesně a kompletně zřízeni uvnitř. To vyžaduje důkladné srovnání mezi adresářem source () a nově vytvořenou uživatelskou základnou, aby bylo zajištěno, že každý uživatelský účet spolu s přidruženými atributy, jako jsou čísla rozšíření a přiřazení přímého vnitřního vytáčení (DID), byly správně migrovány. Úplnost zajišťování je rozhodující nejen pro provozuschopnost prvního dne, ale také pro průběžnou správu a podporu.

Ověření přiřazení čísel zahrnuje potvrzení, že každému uživateli je přiřazena správná přípona a externí číslo a že tato čísla směrují správně jak v interních (on-net), tak externích (PSTN) tocích volání. Je nezbytné zkontrolovat případné překrývání, chybějící přiřazení nebo nesprávné konfigurace, které by mohly vést k chybám směrování hovorů nebo přerušení služby.

PSTN toky hovorů a prezentace ID volajícího

Robustní postup akceptačního testování musí zahrnovat end-to-end validaci toků volání PSTN. To zahrnuje scénáře příchozích i odchozích ho vorů. U příchozích hovorů PSTN by měl testovací tým potvrdit, že hovory jsou doručovány do zamýšlených koncových bodů, ať už se jedná o jednotlivé uživatele, fronty hovorů, skupiny hledání nebo automatické obsluhy. Odchozí hovory PSTN musí být uskutečněny úspěšně, se zvláštním důrazem na správné doručení a prezentaci informací o ID volajícího. To zahrnuje zajištění toho, aby bylo externím příjemcům zobrazeno správné jméno a číslo vol ajícího v souladu s organizačními zásadami a regulačními požadavky.

Testování by mělo také řešit scénáře převzetí služeb při selhání, jako je zpracování nedosa žitelných koncových bodů nebo narušení sítě. To pomáhá potvrdit, že záložní mechanismy a alternativní směrování fungují správně, udržují kontinuitu a spolehlivost služeb.

Toky hovorů v síti

Interní nebo on-net toky hovorů tvoří páteř podnikové komunikace. Testování akceptace v této oblasti ověřuje, zda jsou hovory mezi uživateli v rámci organizace směrovány správně, přičemž funkce, jako je přenos hovorů, pozastavení, přesměrování a konference, fungují podle plánu. Musí být potvrzena integrita čí selných plánů, připojení mezi rozšířením a podporou zásad organizačních volání.

Uživatelské zpracování hovorů a ověření funkcí

Důležitým aspektem akceptačního testování je ověření toho, jak uživatelé zpracovávají hovory pomocí a podpor ovaných stolních telefonů. Tento proces se zaměřuje na potvrzení, že každodenní pracovní postupy volání jsou intuitivní a spolehlivé, a že uživatelé mají bezproblémový přístup k základním funkcím nezbytným pro jejich role. Testování by mělo posoudit snadnost, s jakou mohou uživatelé uskutečňovat a přijímat hovory, spravovat funkce zadržení a obnovení a provádět naslepo i konzultační převody. Je také nezbytné ověřit, zda jsou přesměrování ho vorů, konference a další pokročilé funkce, jako je parkování a načítání hovorů nebo aktivace funkce Nerušit, snadno dostupné a fungují hladce.

Zkušenosti by měly být vyhodnoceny z hlediska jasnosti a odezvy s ohledem na to, jak uživatelé interagují s historií hovorů, hlasovou schránkou a integrovanými adresáři. Další pozornost by měla být věnována schopnosti přesouvat aktivní hovory mezi zařízeními a efektivně používat ovládací prvky hovoru v rámci aplikace nebo na fyzických telefonech. Koneč ným cílem je zajistit, aby prostředí koncového uživatele bylo konzistentní, efektivní a plně podporovalo komunikační potřeby organizace po migraci.

Volací fronty: Zkušenosti s agentem a supervizorem

Fronty hovorů se často používají pro zpracování scénářů příchozích hovorů s velkým objemem. Přijímací testování se zde zaměřuje na několik dimenzí. Nejprve je třeba ověřit, že volání jsou distribuována agentům podle nakonfigurované logiky fronty, jako je round robin, nejdelší nečinnost nebo simultánní vyzvánění. Prezentace hovorů ve frontě na desktopech agentů musí být zkontrolována z hlediska přehlednosti a snadnosti použití, aby bylo zajištěno, že agenti mohou efektivně přijímat, zadržovat a přenášet hovory.

Pro supervizory by prostředí počítače mělo být vyhodnoceno z hlediska funkcí, jako je monitorování v reálném čase, nabízení hovorů a analýza nebo přehled o výkonu fronty. To zahrnuje mimo jiné ověřování řídicích panelů a nástrojů pro vytváření sestav, které poskytují použitelná data o distribuci hovorů, aktivitě agenta a metrikách fronty.

Hunt Groups: Distribuce hovorů

Skupiny lovu jsou klíčovým mechanismem pro distribuci hovorů předdefinovaným skupinám uživatelů. Přijímací testování musí potvrdit, že hovory jsou směrovány členům skupiny na základě nakonfigurovaného loveckého algoritmu a že scénáře přetečení, přesměrování a bez odpovědi jsou zpracovávány podle návrhu. Zajištění toho, aby chování členství ve skupině a směrování hovorů odpovídalo těm, které byly dříve stanoveny, je zásadní pro provozní konzistenci a spokojenost uživatelů.

Automatické obsluhy: Oznámení a operace nabídek

Automatické obsluhy představují přední linii automatizovaného zpracování hovorů. Testování musí zahrnovat přehrávání oznámení, přesnost zaznamenaných pozdravů a správnou funkci stromů nabídek. Výběr nabídky by měl spolehlivě směrovat volající na příslušná oddělení, jednotlivce, nebo externí čísla. Testování by také mělo zahrnovat neplatné scénáře nebo scénáře časového limitu, aby se potvrdilo, že volající dostávají jasné pokyny nebo jsou přesměrováni podle plánu.

Provoz hlasové schránky

Konečně, funkce hlasové schránky je rozhodující pro uživatelskou zkušenost. Přijímací testy by měly ověřit, zda jsou hlasové schránky správně přiřazeny a přístupné, a to jak z organizace, tak vzdáleně. Schopnost zaznamenávat, načítat a spravovat zprávy musí být potvrzena spolu s doručením oznámení.

Optimalizace

Migrace služby PSTN na Cloud Connect pro

Optimalizace místní infrastruktury

Využijte analytiku a řešení problémů

Migrace služby PSTN na Cloud Connect pro

Jakmile jsou všechny koncové body a uživatelé migrováni do cloudového volání, jediným účelem Unified CM je fungovat jako tranzit mezi bránami PSTN a prostřednictvím místní brány. Odstranění brány PSTN a místní brány z obrazu pomocí Cloud Connect jako přístupu PSTN pro všechny Webex Calling uživatele má několik výhod, včetně snížení nákladů a lepší spolehlivosti. Chcete-li převést místní přístup PSTN na Cloud Connect pro , postupujte takto:

Cloud Connect pro výběr partnerů.

Podívejte se na seznam Cloud Connect pro partnery a vyberte si z dostupných partnerů dostupných pro umístění vaší organizace.

Cloud Connect pro ověření.

Před přepnutím přístupu PSTN pro lokality na Cloud Connect je třeba ověřit a ověřit připojení k PSTN prostřednictvím vybraného partnera Cloud Connect. Za tímto účelem je třeba zřídit testovací umístění s ně kterými testovacími uživateli zřízenými v tomto testovacím umístění. Přístup PSTN pro toto testovací místo je poté nastaven na partnera Cloud Connect před ověřením připojení PSTN pomocí testovacích telefonů. Po úspěšném ověření může být testovací umístění zrušen o.

Přenos čísel.

Chcete-li se připravit na přechod na Cloud Connect, je třeba zadat příkaz portů pro všechna čísla aktuálně přiřazená kmenovému portu PSTN, který končí. Všechna čísla musí být přenesena na partnera Cloud Connect. Aby byla zachována dosažitelnost mezi lokacemi, musí být všechna čísla všech míst přenesena současně .

Přepněte na partnera Cloud Connect.

K datu přechodu, přístup PSTN pro všechna umístění v musí být nastaven na poskytovatele služby PSTN připojeného k cloudu, a mělo by být ověřeno příchozí a odchozí připojení.

Jak je popsáno v části PSTN kapitoly návrhu, zákazníci se také mohou rozhodnout přesunout svůj přístup PSTN do Cloud Connect na začátku přechodu pomocí trunkingu PSTN pro hybridní nasazení. Další informace naleznete v tématu trunkování PSTN pro hybridní nasazení. Webex Calling V takovém případě je během přechodu přístup PSTN prostřednictvím místní brány a po přesunutí všech uživatelů neexistuje žádný další krok migrace související s PSTN kromě vyřazení z provozu a místních bran.

Optimalizace místní infrastruktury

Jakmile jsou všichni uživatelé převedeni a všechny koncové body převedeny na cloudovou registraci (nebo byly vy řazeny z provozu), aktualizujte příslušnou místní infrastrukturu nyní, když se používá cloudové volání. Aktualizace infrastruktury zahrnují:

Odeberte místní DNS SRV záznamy řízení hovorů a zpráv z místních server ů DNS včetně serverů cisco_uds. _tcp. <domain>, cup_login. _tcp. <domain>. Tyto záznamy SRV již nejsou potřebné pro zjišťování klientských služeb.

Odstraňte DNS SRV záznamy související s hranami z veřejného systému DNS včetně collab_edge. _tls. <domain>. Tyto záznamy SRV již nejsou vyžadovány pro zjišťování klientských služeb hraničních služeb spolupráce.

Aktualizujte všechny relevantní rozsahy DHCP, abyste odstranili adresy TFTP/spouštěcího serveru možnosti 66 a možnost 150. Tyto rozsahy již nejsou vyžadovány pro zjišť ování a stahování konfigurace řízení volání koncových bodů.

Aktualizovat/odebrat příslušné protějšky v místní bráně/krychli, které směrují hovory do a z. Unified CM Pro místní směrování hovorů již nejsou vyžadovány tyto propojovací moduly.

Odstraňte nebo odeberte všechny virtuální počítače a/nebo servery uzlů clusteru. Podle potřeby přepracujte výpočetní prostředky a hardware . Tyto prostředky již nejsou potřebné pro řízení hovorů a hraniční služby.

Odstraňte nebo odeberte všechny virtuální počítače a/nebo servery uzlů clusteru. Podle potřeby přepracujte výpočetní prostředky a hardware . Tyto prostředky již nejsou potřebné pro hlasovou schránku a služby jednotných zpráv .

Vyčištění: Po migraci přístupu PSTN na Cloud Connected PSTN lze vyřadit kmeny PSTN, brány PSTN a místní bránu z provozu.

U jakéhokoli stávajícího místního řešení E911 odstraňte všechna umístění nebo čísla, která byla migrována, a jakmile je úplný přechod dokončen, odeberte virtuální počítače nebo servery aplikace. Podle potřeby přepracujte výpočetní prostředky a hardware . Tyto zdroje již nejsou potřebné pro tísňové volání a lokalizační služby.

DNS patřící migrovaným uživatelům by měly být umístěny do skrytého oddílu, aby se zabránilo selhání směrování hovorů a aby se zajistilo, že všechny CSS mají prioritní přístup k cloudové cestě stejných DNS.

Aktualizujte fyzickou odesílatelnou polohu a síťový prvek v horizontu mobility, kdykoli dojde ke změnám. Běžné činnosti, které vyžadují aktualizace, jsou:

Výměna síťového přepínače

Výměna bezdrátového přístupového bodu

Změny rozsahu DHCP

Fyzické změny uvnitř budovy (pokud se řeší na kubickou/kancelář)

Rozšíření nebo zmenšení fyzického kancelářského prostoru uvnitř budovy.

Využijte analytiku a řešení problémů

poskytuje komplexní funkce analýzy a odstraňování problémů, které vám pomohou vizualizovat a sledovat nasazení. Ty zahrnují kvalitu médií, podrobnou historii hovorů, frontu hovorů, lo veckou skupinu a analýzu automatické obsluhy. Příklad analýzy kvality médií je uveden na obrázku analýza kvality médií.

analýza kvality médií

V části Odstraňování problémů lze zobrazit každý hovor uskutečněný pomocí s podrobnými informacemi o klíčové kvalitě médií a problémech souvisejících se signalizací, které pomohou určit problémy s médii i neúspěšnými hovory, jak je znázorněno na obrázku Odstraňování problémů s kvalitou médií.

řešení problémů s kvalitou médií

Řešení problémů lze také integrovat s dalšími produkty Cisco, jako jsou přepínače ThousandEyes a Meraki, a poskytnout tak ještě bohatší integrovaný zážitek v Control Hub. Další informace o používání Webex Callinganalytiky a odstraňování problémů naleznete v tématu Řešení potíží Webex Calling s hovory v centru Control Hub.

Úvod

Než začnete

Přehled

Základní komponenty

Přehled procesu PPDIO

Obecný popis PPDIO

Používání PPDIO pro projekty migrace z Unified CM do Webex Calling

Příprava

Plán

Navrhnout

Implementovat

Optimalizovat

Zpětnovazební smyčky PPDIO

Migrační přístup

Než začnete

Tato příručka je určena pro týmy nebo jednotlivce se zkušenostmi s konfigurací a správou Cisco Unified Communications Manager (Unified CM) a koncových bodů Cisco, včetně IP stolních telefonů, videozařízení a softwarových klientů Jabber. V celém tomto dokumentu naleznete odkazy na dokumentaci k produktům a podpůrné dokumentaci, které vám pomohou.

Tento dokument se zaměřuje na přechody z Unified CM pouze na víceklientské prostředí Webex Calling. Termín Webex Calling v tomto dokumentu vždy označuje víceklientskou službu Webex Calling.

Před zahájením migrace z Unified CM na Webex Calling je nezbytné mít komplexní znalosti o řešení Webex Calling a jeho příslušných komponentách. Úspěšná migrace vyžaduje znalost architektury Webex Calling, modelů služeb, možností nasazení a souvisejících funkcí, aby bylo možné správně namapovat stávající úlohy Unified CM a navrhnout efektivní plán přechodu.

Důkladná znalost následujících komponent Webex Calling je nezbytná pro vytvoření efektivní strategie přechodu a provozní připravenosti.

Control Hub

Zřizování adresářů a uživatelů

Platforma pro volání Webex

Podporované volající koncové body

Možnosti připojení k PSTN

Správa čísel a plán volání ve službě Webex

Funkce zabezpečení a dodržování předpisů.

Další informace naleznete v části Preferovaná architektura Cisco pro volání Webex.

Tato příručka zdůrazní nástroje a procesy, které je třeba používat v průběhu celého přechodného cyklu. Přechod z on-premise volání, Unified CM, na novou cloudovou platformu pro volání, Webex Calling, však může být značně náročný s potenciálními obchodními, technickými a složitými výzvami. Aby vám Cisco pomohlo tyto výzvy překonat, nabízí několik různých možností, které vám s vaší cestou pomohou. Je důležité si prostudovat informace na Volání z podnikového cloudu – Migrace volání a porozumět jednotlivým možnostem a tomu, jak vám každá z nich může pomoci s vaší vlastní migrací.

Nástroje pro migraci Webexu: samoobslužné, bezplatné nástroje zabudované v Control Hubu pro zjednodušení přechodu na Webex Calling

Certifikovaní poskytovatelé migrace: Společnost Cisco ověřila poskytovatele softwaru a nástrojů, kteří vyvinuli migrační řešení, jež pomáhají partnerům a zákazníkům Webexu se složitými a rozsáhlými migracemi. Tato řešení mohou pomoci zjednodušit, spravovat a urychlit přechod na Webex Calling.

Pomoc s nastavením Webexu: migrační služba vedená společností Cisco, která provede zákazníky a partnery nasazením a konfigurací služby Webex Calling, což je nezbytné pro úspěšnou migraci uživatelů a služeb Unified CM do služby Webex Calling.

Přehled

S růstem cloudových služeb pro spolupráci se stále více zákazníků snaží přesunout své stávající úlohy spolupráce do cloudu, a to vzhledem k příslibům nižších celkových nákladů na vlastnictví, zjednodušené správy, nepřetržitého dodávání funkcí, větší škálovatelnosti a vynikající spolehlivosti, které jsou vlastní cloudovým službám. Vzhledem k tomu, že se zákazníci chystají přejít z on-premise služeb pro spolupráci na cloudové, je důležité, aby pochopili, co tento přechod obnáší a jaké kroky je k jeho provedení potřeba podniknout.

Účelem tohoto dokumentu je poskytnout pokyny k nasazení zákazníkům, kteří chtějí přejít z on-premise Unified CM na Webex Calling v cloudu. Tato příručka pro nasazení předpokládá, že čtenář má základní znalosti o přechodu volání mezi Unified CM a Webex Calling, včetně toho, co se při tomto přechodu změní a jaké jsou rozdíly při přesunu úlohy volání z lokálního prostředí do cloudu. Než budete pokračovat, ujistěte se, že jste si prostudovali a seznámili se s informacemi dostupnými v mapě přechodu. Tato mapa přechodu poskytuje informace o změnách a rozdílech v tomto přechodu.

Jak je znázorněno na obrázku Architektura spolupráce v místním prostředí: Řízení hovorů a vzdálený přístup, typické lokální nasazení zahrnuje různé komponenty infrastruktury pro spolupráci v síti, platformu pro řízení hovorů, edge platformu, hardwarové a softwarové koncové body a v některých případech i platformy pro konference a plánování. V architektuře Cisco by to zahrnovalo Unified CM pro řízení hovorů, Expressway pro vzdálený přístup a edge služby mezi podniky (B2B) a Cisco Meeting Server. / Cisco Meeting Management pro konference v místní síti, Unity Connection pro hlasové zprávy a hardwarové (IP telefony Cisco, videosystémy Cisco Desk and Room) a softwarové (Cisco Jabber) koncové body založené na IP protokolu orientované na uživatele. Tyto komponenty se mohou v některých prostředích mírně lišit, ale toto je výchozí bod pro přechod popsaný ve zbytku tohoto dokumentu.

Architektura pro spolupráci v místním prostředí: ovládání hovorů a vzdálený přístup

Architektura znázorněná na obrázku Architektura pro spolupráci v místním prostředí: Řízení hovorů a vzdálený přístup je založen na preferované architektuře (PA) pro lokální nasazení Cisco Collaboration Enterprise. Další informace o podnikové platformě Enterprise On-premise naleznete v článku Preferované architektury pro spolupráci společností Cisco.

Před: Tabulka Komponenty infrastruktury pro volání v místním prostředí uvádí klíčové prvky architektury v místním prostředí před přechodem na Webex Calling v cloudu.

Tabulka 1. Před: Komponenty infrastruktury pro volání v místních podmínkách
Produkt Popis

Služba Unified CM Místní řízení hovorů poskytující služby registrace zařízení a směrování hovorů

Cisco Expressway-C/E Okrajová infrastruktura poskytující mobilní a vzdálený přístup (MRA) a funkce pro vztahy mezi podniky (B2B), která umožňuje vzdáleným koncovým bodům bezpečné připojení zvenčí organizace. Expressway je nasazen ve dvojicích, aby zajistil průchod firewallem pro externí koncové body.

Cisco Meeting Server (CMS), Cisco Meeting Management (CMM) a Cisco Telepresence Management Suite (TMS) Místní infrastruktura pro hlasové, video a webové konference poskytující možnosti vícebodových schůzek, správy schůzek a plánování. [Optional]

Cisco Unity Connection Místní platforma pro hlasové zprávy poskytující funkce hlasové schránky a sjednoceného zasílání zpráv. [Optional]

Cisco Desk, Cisco Room, Cisco Board, Cisco IP telefony a Cisco Jabber Zařízení založená na IP protokolu registrovaná v Unified CM a poskytující možnosti hlasových a videohovorů

Jak je znázorněno na obrázku , rozhodnutí o přechodu: Místní volání do Webex Calling, zákazníci, kteří mají místní řízení hovorů s Unified CM a koncovými body pro stolní počítače a video IP, mají možnost přejít na cloudovou architekturu Webex Calling.

Rozhodnutí je třeba učinit na základě funkčních požadavků zákazníka. Zákazníci s následujícími požadavky by měli toto rozhodnutí pečlivě zvážit a nakonec se mohou rozhodnout ponechat si řízení hovorů v místním prostředí:

Modely telefonů, které nejsou podporovány službou Webex Calling

Složité nebo četné integrace s jinými lokálními systémy či řešeními, zejména tam, kde je replikace těchto integrací s Webex Calling obtížná nebo nejsou k dispozici žádná ekvivalentní alternativní řešení.

Komplexní plán vytáčení, vysoce detailní třídy služeb nebo obojí

Omezený, omezený nebo nespolehlivý přístup k internetu

Přísné zásady ochrany osobních údajů a vlastnictví

Požadavek na shodu s předpisy pro nahrávání a ukládání médií v prostorách organizace nebo v rámci země

Integrace třetích stran bez funkční alternativy pro integraci Webex Calling

Integrace kontaktních center, kde se rozhraní kontaktního centra zatím nepřesouvá do cloudu.

Rozhodnutí o přechodu: volání z místních služeb do služby Webex Calling
Zákazníci, kteří chtějí začít využívat cloudové volací služby, by měli zvážit Webex Calling. Tato cloudová volací služba umožňuje zákazníkovi využít globální architekturu Webexu pro škálování a konektivitu. Účastníci v podnikové síti a vzdálení účastníci mimo podnikovou síť mohou komunikovat pomocí hardwarových koncových bodů založených na IP protokolu. and/or desktopové nebo mobilní softwarové klientské aplikace.

Tento dokument se zaměřuje na zákazníky s nasazením řízení hovorů Unified CM, kteří chtějí porozumět obecným krokům, aspektům a požadavkům pro aktivaci nasazení Webex Calling, jak je popsáno v následující části.

Základní komponenty

Cílová architektura pro tuto migraci zahrnuje několik nových komponent. Patří sem služba Webex Calling pro cloudové volání, aplikace Webex, Cisco Directory Connector pro integraci identit a Local Gateway (LGW) pro přístup k PSTN, a také integrace volání z místních sítí do cloudu. Dalšími možnostmi přístupu k PSTN jsou volací tarify Cisco nebo cloudově připojená PSTN (CCP) zprostředkovaná partnerem Cloud Connect for Webex Calling.

Jak je znázorněno na obrázku po: Architektura volání Webex, nové komponenty (volání Webex, konektor adresáře, lokální brána a brána pro zajištění přežití) jsou přidány do stávajícího místního nasazení.

Po: Architektura volání Webex

Po: Tabulka Komponenty infrastruktury cloudového volání uvádí nové prvky architektury po přechodu na Webex.

Tabulka 2. Po: Komponenty infrastruktury cloudového volání
Produkt Popis

Webex Calling Cloudová volací služba poskytovaná z platformy Webex a zajišťující registraci koncových bodů a směrování hovorů

Konektor adresáře Cisco Aplikace pro systém Windows spuštěná na počítači s doménou Windows, která zajišťuje synchronizaci identit mezi podnikovou místní službou Active Directory a úložištěm identit organizace Webex.
Pro zákazníky, kteří přecházejí z místní služby Active Directory na Entra ID, se pro integraci identity s Webexem namísto Cisco Directory Connectoru používá aplikace Entra ID Wizard.

Místní brána Lokální brána funguje jako most mezi místní sítí sjednocené komunikace zákazníka a cloudem Webex Calling. Lze jej nasadit lokálně nebo hostovat u partnera a poskytovat tak přístup k PSTN pro koncové body registrované v cloudu a také integraci volání mezi koncovými body registrovanými v Unified CM a cloudu. Směrovač s integrovanými službami Cisco IOS-XE (řada ISR 1100 a 4000), Cisco Catalyst 8200/8300 Řada Cisco, software Cisco Catalyst 8000V Edge a různé certifikované řadiče Session Border Controller (SBC) třetích stran lze použít jako LGW pro postupnou migraci.

Brána Survivability Survivability Gateway (SGW) je lokální síťová brána založená na IOS-XE, která poskytuje záložní volací služby pro koncové body Webex Calling na místě během výpadků sítě.

Volací plán Cisco, Cloud Connect pro volání přes Webex Cisco Calling Plan a Cloud Connect pro Webex Calling jsou cloudové možnosti pro přístup k PSTN pro koncové body Webex Calling. Přístup k PSTN je usnadněn poskytovatelem cloudové PSTN a nevyžaduje žádné místní vybavení.

Aplikace Webex Klientská aplikace běžící na desktopovém operačním systému (Windows, Mac) nebo mobilním operačním systému (Android, iOS) a registrovaná přímo na platformě Webex Calling pro funkce volání.

Přehled procesu PPDIO

Proces PPDIO je zkratka pro přípravu, plánování, návrh, implementaci a optimalizaci. Jedná se o strukturovanou metodologii společnosti Cisco, která vede projekty od počátečního posouzení až po neustálé zlepšování a zajišťuje efektivní a úspěšné nasazení nebo migrace.

Proces PPDIO

Obecný popis PPDIO

Připravit: Zhodnoťte aktuální prostředí, shromážděte požadavky a slaďte zainteresované strany s cílem vytvořit pevný základ.

Plán: Vypracovat podrobné projektové plány včetně časových harmonogramů, zdrojů a strategií pro zmírnění rizik.

Design: Navrhněte cílové řešení přizpůsobené obchodním a technickým potřebám.

Nářadí: Proveďte nasazení nebo migraci dle návrhu a ověřte funkčnost a výkon.

Optimalizovat: Neustále vylepšujte řešení po implementaci sledováním výkonu, zdokonalováním konfigurací a využíváním automatizačních a integračních nástrojů.

Používání PPDIO pro projekty migrace z Unified CM do Webex Calling

Při přechodu z Unified CM na Webex Calling poskytuje proces PPDIO jasný plán pro zajištění plynulého a efektivního přechodu:

Příprava

Posouzení stávajícího prostředí Unified CM a připravenosti na migraci

Shromažďujte podrobná data o uživatelích, zařízeních, síti a závislostech

Shromažďujte podrobnosti o poloze, včetně adresy pro nouzové situace, počtu uživatelů, přístupu k internetu a přístupu k PSTN

Identifikujte rizika a definujte rozsah projektu tak, aby se sladil postup všech zúčastněných stran.

Plán

Vytvořte komplexní plán migrace s dávkovými harmonogramy, přiřazením zdrojů a časovými harmonogramy

Definování úkolů, jako jsou aktualizace firmwaru zařízení, poskytování licencí a zaškolování uživatelů

Koordinujte migrační okna se společností Cisco a partnery, abyste minimalizovali narušení.

Navrhnout

Mapování aktuálních konfigurací, plánů vytáčení a uživatelských profilů Unified CM na ekvivalenty Webex Calling

Návrh prostředí Webex Calling, včetně strategie PSTN (průběžné a konečné), umístění, uživatelských rolí a integračních bodů, jako je Local Gateway (CUBE) a synchronizace adresářů

Naplánujte scénáře koexistence, kde Unified CM a Webex Calling fungují během migrace současně.

Implementovat

Používejte migrační nástroje Control Hub spolu s nástroji třetích stran k provádění změn režimu firmwaru zařízení, konfigurace funkcí a migrací uživatelů.

Využívejte hromadné operace a zřizování pomocí rozhraní Webex API pro zefektivnění rozsáhlých migrací a konfigurací

Provádět zřizování licencí, registraci zařízení a aktualizace konfigurace

Ověřte úspěšnost migrace testováním a provozním ověřením.

Optimalizovat

Neustále monitorujte výkon a uživatelskou zkušenost služby Webex Calling

Upřesněte konfigurace a pracovní postupy na základě provozních dat a zpětné vazby

Využijte automatizační a integrační možnosti pro zvýšení efektivity a škálovatelnosti

Vyřaďte z provozu starší komponenty Unified CM dle potřeby a poskytněte průběžnou podporu pro provoz 2. dne.

Tento vylepšený přístup PPDIO zajišťuje kontrolovanou, transparentní a efektivní migraci z Unified CM na Webex Calling a využívá nástroje, API a partnerský ekosystém společnosti Cisco k udržení kontinuity podnikání a zlepšení možností spolupráce.

Zpětnovazební smyčky PPDIO

Přehled na vysoké úrovni znázorněný na obrázku Iterace při provádění PPDIO ilustruje jednu zpětnovazební smyčku z fáze optimalizace zpět do fáze přípravy. To znamená, že po počáteční implementaci existuje možnost neustálého zlepšování. Každý cyklus optimalizace může identifikovat nové požadavky nebo oblasti pro vylepšení, které lze řešit prostřednictvím následných projektů nebo iniciativ. Tyto jednotlivé projekty postupně sledují zavedený životní cyklus PPPIO (Příprava, Plánování, Návrh, Implementace, Optimalizace). Tento iterativní přístup zajišťuje, že systém zůstává v souladu s vyvíjejícími se obchodními cíli a technologickým pokrokem, a podporuje tak kulturu neustálého zdokonalování a přizpůsobivosti.

Iterace při provádění PPDIO

Během provádění procesu PPPDIO je běžné, že zjištění v pozdějších fázích vyžadují přezkoumání a případnou revizi rozhodnutí učiněných v dřívějších fázích. Například problémy, které se vyskytly během fáze implementace, jako je identifikace nejasností v návrhu nebo chybějících detailů, mohou odhalit, že určité aspekty nebyly během fáze návrhu plně řešeny. V takových případech je nutné se před dalším postupem vrátit k příslušné dřívější fázi, aby se tyto problémy vyřešily. Tento iterativní mechanismus zpětné vazby, jak je znázorněno na obrázku , zajišťuje , že řešení je důkladně ověřeno a zdokonaleno, což v konečném důsledku přispívá k robustnějšímu a efektivnějšímu nasazení.

Sjednocený proces PPPIO s asistencí CM

Při přechodu z Unified CM na Webex Calling může každá fáze procesu PPPDIO významně těžit z informací shromážděných ze stávajícího prostředí Unified CM. Například z aktuální konfigurace Unified CM lze extrahovat komplexní seznamy uživatelů, telefonních čísel, funkcí volání a komponent plánu vytáčení. Tato data doplňují informace poskytované přímo zúčastněnými stranami a pomáhají zefektivnit plánovací a projektové činnosti. Využití vhodných nástrojů k automatizaci extrakce a analýzy dat nejen zvyšuje přesnost, ale také urychluje celý proces. Využitím poznatků ze stávajícího nasazení lze přechod na Webex Calling provést efektivněji než tradiční implementaci na zelené louce, a to při zachování strukturované metodologie PPDIO. Tento proces je znázorněn na obrázku Sjednocený proces PPPDIO s asistencí CM.

Migrační přístup

Při plánování přechodu z on-premise Unified CM na Webex Calling je třeba určit, jak k této cestě přistoupíte. Nejprve se budete muset rozhodnout, zda migrace bude blesková (vše najednou) nebo fázovaná (migrace skupin users/devices po delší dobu).

Provedení bleskové migrace přesune všechny vaše uživatele a zařízení nejrychleji. Touto metodou přesunete všechny uživatele a zařízení z místního Unified CM do Webex Calling současně. V podstatě se jedná o jedno migrační okno pro všechny uživatele a zařízení. Po dokončení této migrace budou všichni vaši uživatelé a zařízení na platformě Webex Calling a veškerou infrastrukturu Unified CM lze vyřadit z provozu. Mnoho organizací však tento přístup nemůže použít kvůli rozsahu a velikosti svého nasazení volání.

Druhý přístup je fázovaná migrace. Většina organizací tento přístup použije, protože poskytuje lepší kontrolu, správu a škálovatelnost při migraci. Také se lépe hodí pro větší nasazení sjednocené komunikace. and/or nasazení ve více regionech. Tento dokument se proto zaměřuje na fázovaný přístup se dvěma kroky přechodu.

Jak je znázorněno na obrázku níže Fázovaný přechod volání: Hybridní a cloudové, první přechodná fáze (fáze 1) vede k nasazení koexistence s duálními volacími prostředími. V této fázi jsou někteří uživatelé, zařízení a softwaroví klienti převedeni na Webex Calling, zatímco jiní stále používají místní řízení hovorů Unified CM. Závěrečná přechodová fáze (fáze 2) vede k čistě cloudovému prostředí pro volání, kde všichni uživatelé, zařízení a softwaroví klienti byli plně převedeni na platformu Webex Calling.

Jak dlouho bude organizaci trvat, než kompletně přejde na cloudové volání, se bude lišit v závislosti na jejím aktuálním nasazení. V některých případech může organizace provést počáteční přechod a zůstat ve fázi koexistence duálního řízení hovorů (fáze 1) po delší dobu (měsíce nebo dokonce roky), zatímco v jiných případech může organizace plně přejít na Webex Calling (fáze 2) ve velmi krátkém období (týdny nebo měsíce). Tento dokument má pokrýt obě fáze (fázi 1 – koexistenci a fázi 2 – plně transformovanou).

Fázovaný přechod volání: hybridní a cloudové

Je možné, že některé organizace si budou moci udržovat koexistenci duálního nasazení řízení hovorů na dobu neurčitou bez plánů na úplný přechod na cloudové volání.

Druhým faktorem je, jak budete převádět uživatele, zařízení a softwarové klienty z místního řízení hovorů do cloudového řízení hovorů. Doporučený přístup je třífázový přechod. Obrázek Doporučený třífázový přechod níže rozděluje tento přístup do 3 fází.

Doporučený třífázový přechod

Před migrací: Tato fáze se zaměřuje na přípravu prostředí Webex i Unified CM na migraci. Nejde o volání konkrétního plánování nebo konfigurací, ale o zaměření na dokončení aktivit, které lze provést nyní a před zahájením jakéhokoli projektu migrace Webex Calling. Cílem je vybudovat základy pro obě prostředí a připravit je na migraci.

Příprava na migraci: V této fázi začíná úsilí o přípravu migrace na Webex Calling. Zde je třeba přezkoumat a aktualizovat obchodní a technické požadavky. Nejenže zvedáte a přesouváte to, co je aktuálně nasazeno s Unified CM, ale místo toho předefinujte obchodní a technické požadavky, které vaše společnost potřebuje dnes i v budoucnu, s využitím možností Webex Calling. Kromě toho je to fáze, ve které dokončíte návrh, plánování konfigurace a migraci. planning/schedule.

Migrace (zavedení a vyřazení z provozu): V této fázi dochází ke skutečné migraci uživatelů, zařízení, telefonních čísel a softwarových klientů. Jak je uvedeno výše, tuto fázi lze dokončit pro všechny najednou (bleskové řezání) nebo v průběhu více změnových oken (postupné řezání). Plány pro přijetí koncovými uživateli, školení a komunikace jsou zásadní, aby si vaši uživatelé byli vědomi změn, toho, jak používat novou platformu pro volání, a věděli, kdy ke změně dojde. Posledním krokem je vyřazení veškeré místní infrastruktury sjednocené komunikace, která se již nepoužívají.

Fáze před migrací zahrnuje aktivity (povinné, doporučené a volitelné), na kterých můžete okamžitě začít pracovat. Doporučuje se tyto kroky dokončit dříve než později a nejlépe před zahájením projektu. Dokončení některých aktivit může trvat déle, proto jejich dřívější zahájení pomůže zefektivnit samotný migrační projekt.

Obrázek Aktivity před migrací níže zdůrazňuje pět konkrétních kategorií aktivit, které souvisejí s migrací Webex Calling.

Předmigrační aktivity

Tabulka 1. Před: Komponenty infrastruktury pro volání v místních podmínkách
Produkt	Popis
Služba Unified CM	Místní řízení hovorů poskytující služby registrace zařízení a směrování hovorů
Cisco Expressway-C/E	Okrajová infrastruktura poskytující mobilní a vzdálený přístup (MRA) a funkce pro vztahy mezi podniky (B2B), která umožňuje vzdáleným koncovým bodům bezpečné připojení zvenčí organizace. Expressway je nasazen ve dvojicích, aby zajistil průchod firewallem pro externí koncové body.
Cisco Meeting Server (CMS), Cisco Meeting Management (CMM) a Cisco Telepresence Management Suite (TMS)	Místní infrastruktura pro hlasové, video a webové konference poskytující možnosti vícebodových schůzek, správy schůzek a plánování. [Optional]
Cisco Unity Connection	Místní platforma pro hlasové zprávy poskytující funkce hlasové schránky a sjednoceného zasílání zpráv. [Optional]
Cisco Desk, Cisco Room, Cisco Board, Cisco IP telefony a Cisco Jabber	Zařízení založená na IP protokolu registrovaná v Unified CM a poskytující možnosti hlasových a videohovorů

Tabulka 2. Po: Komponenty infrastruktury cloudového volání
Produkt	Popis
Webex Calling	Cloudová volací služba poskytovaná z platformy Webex a zajišťující registraci koncových bodů a směrování hovorů
Konektor adresáře Cisco	Aplikace pro systém Windows spuštěná na počítači s doménou Windows, která zajišťuje synchronizaci identit mezi podnikovou místní službou Active Directory a úložištěm identit organizace Webex. Pro zákazníky, kteří přecházejí z místní služby Active Directory na Entra ID, se pro integraci identity s Webexem namísto Cisco Directory Connectoru používá aplikace Entra ID Wizard.
Místní brána	Lokální brána funguje jako most mezi místní sítí sjednocené komunikace zákazníka a cloudem Webex Calling. Lze jej nasadit lokálně nebo hostovat u partnera a poskytovat tak přístup k PSTN pro koncové body registrované v cloudu a také integraci volání mezi koncovými body registrovanými v Unified CM a cloudu. Směrovač s integrovanými službami Cisco IOS-XE (řada ISR 1100 a 4000), Cisco Catalyst 8200/8300 Řada Cisco, software Cisco Catalyst 8000V Edge a různé certifikované řadiče Session Border Controller (SBC) třetích stran lze použít jako LGW pro postupnou migraci.
Brána Survivability	Survivability Gateway (SGW) je lokální síťová brána založená na IOS-XE, která poskytuje záložní volací služby pro koncové body Webex Calling na místě během výpadků sítě.
Volací plán Cisco, Cloud Connect pro volání přes Webex	Cisco Calling Plan a Cloud Connect pro Webex Calling jsou cloudové možnosti pro přístup k PSTN pro koncové body Webex Calling. Přístup k PSTN je usnadněn poskytovatelem cloudové PSTN a nevyžaduje žádné místní vybavení.
Aplikace Webex	Klientská aplikace běžící na desktopovém operačním systému (Windows, Mac) nebo mobilním operačním systému (Android, iOS) a registrovaná přímo na platformě Webex Calling pro funkce volání.

Příprava

Obchodní a technické požadavky

Proč je shromažďování požadavků důležité:

Obchodní požadavky

Technické požadavky

Připravenost sítě a požadavky

Nastavení sjednocené komunikace připojené ke cloudu

Posouzení současného prostředí

Licence

Locations/Sites

Stávající zásoby devices/clients

Ověření způsobilosti zařízení

Uživatelé

Připojení k síti PSTN

Funkce & využití funkcí

Integrace Cisco: Unity Connection UCCX UCCE

Nahrávání hovorů

Integrace třetích stran

Obchodní a technické požadavky

Při plánování migrace z platformy .NET na platformu .NET je klíčové během fáze plánování důkladně shromáždit technické i obchodní požadavky. Tento krok zajišťuje, že migrace bude v souladu s provozními cíli a technickými možnostmi vaší organizace, čímž se minimalizují rizika a narušení provozu.

Proč je shromažďování požadavků důležité:

Sladí obchodní cíle: Pochopení obchodních potřeb pomáhá přizpůsobit migraci tak, aby podporovala klíčové pracovní postupy, uživatelskou zkušenost a plány růstu.

Zajišťuje technickou kompatibilitu: Včasná identifikace technických požadavků předchází problémům s integrací se stávající infrastrukturou, sítí a koncovými body.

Usnadňuje plánování zdrojů: Jasné požadavky pomáhají přesně odhadnout časové harmonogramy, náklady a potřebné zdroje.

Zmírňuje rizika: Včasné odhalení potenciálních problémů umožňuje proaktivní řešení, čímž se zkrátí prostoje a přerušení služeb.

Obchodní požadavky

Mezi typické obchodní požadavky patří:

Počet uživatelů a umístění k migraci

Požadované funkce a služby (například směrování hovorů, hlasová schránka, konference, automatické telefonní operátory, fronty hovorů)

Zásady dodržování předpisů a zabezpečení

Rozpočtová omezení a očekávané náklady

Potřeby pro školení a podporu uživatelů

Harmonogram migrace a aspekty kontinuity provozu.

Shromáždění požadovaných funkcí a služeb je klíčovým krokem k zajištění toho, aby nový systém splňoval obchodní potřeby. Při shromažďování těchto požadavků je důležité nejen zvážit, co je aktuálně nakonfigurováno, ale pokusit se shromáždit skutečné požadavky od obchodních subjektů, které budou systém používat. Jinak existuje riziko, že plán je založen na neaktuálních předpokladech. Nezapomeňte si vyhodnotit další nebo vylepšené funkce dostupné v aplikaci , které v aplikaci nemusí existovat, jako je například cloudové volání, pokročilé fronty hovorů a . To pomáhá plně využít výhod cloudové platformy.

Při vyhodnocování aktuální konfigurace v systému je důležité si uvědomit, že ne všechna stávající nastavení mohou zůstat nezbytná kvůli vyvíjejícím se požadavkům v průběhu životního cyklu systému. Důraz by měl být kladen na identifikaci a uchování pouze těch konfigurací, které odpovídají současným i budoucím potřebám nasazení.

Soustřeďte se více na to, co potřebujete, než na to, co máte.

Zásady dodržování předpisů a zabezpečení jsou klíčovými aspekty během migrace z Webex Calling, aby se zajistilo, že nový cloudový komunikační systém splňuje právní, regulační a organizační standardy.

Dodržování předpisů: Organizace musí ověřit, zda splňují specifické předpisy pro dané odvětví, jako je GDPR, HIPAA nebo SOX, které se týkají požadavků na ochranu osobních údajů, uchovávání a zpracování dat, a také specifických požadavků dané země týkajících se umístění dat, obcházení mýtného a lokality médií.

Zabezpečení dat: Zajištění šifrování hlasových a signalizačních dat jak během přenosu, tak i v klidu, aby se zabránilo zachycení nebo neoprávněnému přístupu.

Řízení přístupu: Definování a vynucování ověřování uživatelů, autorizace a přístupu na základě rolí, aby se zabránilo neoprávněnému použití komunikačních zdrojů.

Audit a monitorování: Implementace funkcí protokolování a monitorování pro sledování přístupu a používání pro účely auditů shody s předpisy a vyšetřování bezpečnostních incidentů.

Sladění politik: Sladění migrace se stávajícími firemními bezpečnostními politikami, včetně zabezpečení koncových bodů, segmentace sítě a plánů reakce na incidenty.

Zajištění bezpečnosti dodavatele: Vyhodnocování bezpečnostních certifikací a osvědčení o shodě s předpisy společnosti Cisco za účelem zajištění důvěryhodnosti.

Řešení těchto zásad dodržování předpisů a zabezpečení během fáze plánování pomáhá zmírnit rizika, vyhnout se právním sankcím a zachovat integritu a důvěrnost komunikace během migrace i po ní.

Školení uživatelů a potřeby podpory jsou nezbytnými součástmi během migrace z na, aby byl zajištěn hladký přechod a přijetí uživateli. Mezi klíčové aspekty patří:

Tréninkové programy: Vypracujte školení na míru pro různé skupiny uživatelů (koncové uživatele, administrátory, pracovníky helpdesku), abyste je seznámili s funkcemi, uživatelskými rozhraními a novými pracovními postupy.

Dokumentace: Poskytněte jasné a přístupné uživatelské příručky, často kladené otázky a stručné referenční materiály, včetně zdrojů Co je nového a odlišného a podrobných návodů „ Před a po “ (ve formátu videa nebo stručného průvodce), abyste uživatelům pomohli s adaptací na aktualizované prostředí po migraci.

Řízení změn: Proaktivně komunikujte změny, abyste řídili očekávání uživatelů a snižovali odpor.

Nosná konstrukce: Vytvořte specializovaný tým podpory nebo eskalační cestu pro rychlé řešení problémů uživatelů během migrace a po ní.

Průběžné vzdělávání: Naplánujte si průběžné aktualizace školení s tím, jak budou vydávány nové funkce nebo aktualizace v aplikaci .

Mechanismy zpětné vazby: Zaveďte kanály, které uživatelům umožní hlásit problémy a poskytovat zpětnou vazbu za účelem zlepšení procesů školení a podpory.

Řešení těchto potřeb v oblasti školení a podpory během fáze plánování pomáhá minimalizovat narušení provozu, zvyšuje důvěru uživatelů a maximalizuje výhody migrace na .

Technické požadavky

Pro úspěšnou migraci z platformy .NET na platformu .NET je třeba shromáždit a zdokumentovat několik klíčových technických požadavků, včetně podrobností o:

Připravenost sítě a kapacita šířky pásma

Komplexní posouzení sítě je zásadní pro zajištění toho, aby vaše stávající infrastruktura mohla podporovat nové prostředí Webex Calling. Zahrnuje:

Analýza šířky pásma: Vyhodnocení aktuálního a plánovaného využití šířky pásma pro zpracování hlasového, video a datového provozu bez přetížení.

Kvalita služeb (QoS): Implementace zásad QoS pro prioritizaci hlasového provozu a minimalizaci latence, jitteru a ztráty paketů.

Připojení k WAN a internetu: Ověření, zda WAN linky a internetová připojení splňují požadavky pro cloudové volání, včetně redundance a funkcí failoveru.

Konfigurace firewallu a NAT: Zajištění, aby nastavení firewallu a NAT povolovala požadovanou signalizaci a mediální provoz pro .

Integrace se stávajícím systémem

Bezproblémová integrace se stávajícími podnikovými systémy je nezbytná pro uživatelskou zkušenost a kontinuitu pracovních postupů:

Adresářové služby: Posouzení integrace s podnikovým adresářem pro automatizované zřizování a ověřování uživatelů.

CRM a obchodní aplikace: Identifikace integračních bodů se systémy pro řízení vztahů se zákazníky a dalšími kritickými obchodními aplikacemi.

Propojení starších ústředen: Plánování strategií koexistence nebo postupné migrace, pokud během přechodu zůstanou nějaké starší telefonní systémy.

Kompatibilita a zřizování koncových bodů

Všechny koncové body včetně stolních telefonů, softwarových telefonů a mobilních zařízení by měly být vyhodnoceny z hlediska kompatibility:

Podpora zařízení: Ověření, zda jsou stávající IP telefony a zařízení podporovány, nebo identifikace požadovaných náhrad.

Procesy zajišťování: Zavedení automatizovaných nebo zjednodušených metod zřizování pro efektivní zavádění koncových bodů.

Aktualizace firmwaru a softwaru: Plánování nezbytných aktualizací pro zajištění interoperability a zabezpečení.

Konfigurace zabezpečení a šifrovací standardy

Bezpečnost je v cloudové komunikaci prvořadá:

Šifrování: Vynucování end-to-end šifrování pro signalizaci a mediální streamy v souladu s osvědčenými bezpečnostními postupy společnosti Cisco.

Autentizace a řízení přístupu: Implementace mechanismů bezpečného ověřování (jako je SSO, vícefaktorové ověřování) a podrobné kontroly přístupu uživatelů.

Dodržování: Zajištění, aby řešení splňovalo příslušné regulační a oborové standardy (například GDPR, HIPAA).

Monitorování zabezpečení: Integrace s nástroji SIEM a nastavení upozornění na potenciální bezpečnostní incidenty.

Tabulka 1. Příklad hodnocení
Požadavek Klíčové aspekty

Připravenost sítě a šířka pásma Šířka pásma, QoS, WAN/Internet, Firewall/NAT

Integrace se stávajícími systémy Adresář, CRM, ústředna, Email/Calendar

Kompatibilita a zřizování koncových bodů Podpora zařízení, zřizování, aktualizace firmwaru

Konfigurace zabezpečení a šifrování Šifrování, ověřování, dodržování předpisů, monitorování zabezpečení

Školení uživatelů a řízení změn Školicí programy, dokumentace, komunikace změn

Přenositelnost čísla a vytáčecí plán Číslo migration/porting, překlad plánu vytáčení

Integrace třetích stran Paging, kontaktní centrum, fax, analogová zařízení

Připravenost sítě a požadavky

Připravenost na síť je klíčová pro úspěšnou migraci na jakékoli cloudové řešení pro volání, jako je . Špatné plánování sítě může vést ke zhoršené kvalitě hovorů, výpadkům hovorů a nespokojenosti uživatelů. Zákazníci musí před migrací na . Doporučuje se ověřit dostupnost šířky pásma sítě pro očekávaný objem hovorů, zajistit splnění požadavků na kvalitu služeb (QoS) a porozumět různým portům, které je nutné otevřít v okrajovém firewallu (firewallech).

Spolehlivé síťové připojení s dostatečnou kvalitou služeb (šířka pásma, ztráta paketů, RTT) je základním požadavkem pro zajištění co nejlepšího uživatelského zážitku napříč všemi koncovými body, klienty a aplikacemi s podporou hlasu a videa, které používají .

Zákazníci a partneři mají k dispozici možnosti připojení nad rámec OTT (Over-the-top Internet), které mohou optimalizovat připojení tak, aby zahrnovalo Webex Edge Connect. Další informace o detailech návrhu Webex Edge Connect naleznete v článku Preferovaná architektura Cisco pro Webex Edge Connect pro Webex Meetings, volání více klientů a vyhrazenou instanci.

Zákazníci mohou využít CScan pro vyhodnocení sítě, které poskytuje informace o kvalitě sítě zákazníka, počtu navázaných hovorů, latenci a tak dále. Další informace o nástroji CScan naleznete v článku Použití nástroje CScan k testování kvality sítě Webex Calling.

Abyste se ujistili, že je síť připravena na migraci na , zvažte následující kontrolní seznam:

Plánování šířky pásma

Vypočítejte si souběžné hovory na lokalitu, abyste zajistili dostatečnou šířku pásma pro upstream i downstream a zahrnuli prostor pro další provoz kritický pro podnikání a budoucí růst.

Tabulka výpočtů šířky pásma pro typy volání Webex Calling zobrazuje typy volání dostupné s nasazením spolu s kodekem a maximální šířkou pásma požadovanou pro každý typ volání. Jak je uvedeno v tabulce výpočty šířky pásma pro typy hovorů Webex Calling, požadovanou šířku pásma pro audio hovory pro každý typ hovoru lze vypočítat pomocí následujícího obecného vzorce:

Počet očekávaných souběžných hovorů * Šířka pásma na hovor v závislosti na kodeku = Požadovaná propustnost sítě.
Tabulka 2. Výpočty šířky pásma pro typy hovorů Webex Calling
Typy hovorů Kodek - šířka pásma Výpočty šířky pásma
/ Stolní telefon -> OPUS - 70 kb/s Počet souběžných hovorů * 70 kb/s = Požadovaná propustnost sítě
/ Stolní telefon -> Stolní telefon OPUS – 70 kb/s Počet souběžných hovorů * 70 kb/s = Požadovaná propustnost sítě
/ Stolní telefon -> PSTN přes LGW G.711 – 80 kb/s Počet souběžných hovorů * 80 kb/s = Požadovaná propustnost sítě
/ Stolní telefon -> PSTN přes cloudovou PSTN (např. volací tarif Cisco) G.711 – 80 kb/s Počet souběžných hovorů * 80 kb/s = Požadovaná propustnost sítě
/ Stolní telefon -> Podnik přes LGW G.722 – 80 kb/s Počet souběžných hovorů * 80 kb/s = Požadovaná propustnost sítě
/ Stolní telefon -> hlasová schránka OPUS – 70 kb/s Počet souběžných hovorů * 70 kb/s = Požadovaná propustnost sítě

Sečtením souběžné požadované propustnosti sítě pro každý typ volání lze určit celkovou potenciální požadavek na šířku pásma pro konkrétní lokalitu.

Všechny volací větve jsou vždy ukotveny na přístupových SBC. Pro určení požadované šířky pásma internetu pro dané místo je třeba vzít v úvahu nejen volání mezi lokalitami, ale také volání v rámci lokality a volání do a z lokální brány v daném místě. Například hovor v rámci lokality mezi dvěma telefony MPP by vyžadoval až 2 x 70 kb/s plně duplexní připojení k internetu v dané lokalitě.

Tabulka Příklady výpočtu šířky pásma pro Webex Calling ukazuje příklad kompletního výpočtu šířky pásma za předpokladu, že všechna zařízení jsou na stejném místě.
Tabulka 3. Příklady výpočtu šířky pásma pro volání ve Webexu
Typy hovorů Počet souběžných hovorů Celková šířka pásma
Aplikace Webex / Stolní telefon → Aplikace Webex 15 2 * 15 * 70 kb/s = 2 100 kb/s
Aplikace Webex / Stacionární telefon → Stacionární telefon 15 2 * 15 * 70 kb/s = 2 100 kb/s
Aplikace Webex / Pevná linka → PSTN přes LGW 50 2 * 50 * 80 kb/s = 8 000 kb/s
Aplikace Webex / Stolní telefon → PSTN přes Cloud Connect pro volání přes Webex 0 0 * 80 kb/s
Aplikace Webex / Pevná linka → Podnik přes LGW 15 2 * 15 * 80 kb/s = 2 400 kb/s
Aplikace Webex / Stacionární telefon → Webex Calling Hlasová schránka 5 5 * 70 kb/s = 350 kb/s
Celkový počet hovorů / Šířka pásma 100 hovorů 14 950 kb/s / 14,95 Mb/s

Všechny hodnoty šířky pásma ve výše uvedených tabulkách se vztahují k šířce pásma IP. Šířka pásma spojení je vyšší v závislosti na zapouzdření WAN.

Šířka pásma ve výše uvedených tabulkách je pro audio hovory. Pro šířku pásma videohovorů, aplikaci Webex a MPP 8845/65 Telefony podporují video H.264 s maximálním rozlišením 720p a maximální šířkou pásma 1 500 kb/s na hovor. Množství šířky pásma spotřebované v jakémkoli okamžiku hovoru však bude kolísat v závislosti na proměnné bitové rychlosti, která je vlastní videokomunikaci.

Kvalita služeb (QoS)

Implementujte zásady QoS ve vašem místním prostředí, abyste upřednostnili provoz v reálném čase a zajistili dodržování QoS napříč přepínači, směrovači a firewally.

Cíle latence, jitteru a ztráty paketů

Pro optimální kvalitu hlasu při hovorech přes OTT (Over-the-Top) a internet se doporučují následující prahové hodnoty:

Latence - méně než 100 ms jednosměrně

Jitter - méně než 10 ms

Ztráta paketů - 0,5 % nebo méně.

Firewall a NAT

Ujistěte se, že je firewall nakonfigurován tak, aby povolil provoz, jak je uvedeno v článku dostupném na adrese Informace o referenčních portech pro volání Webex. Dále povolte přístup k doménám a rozsahům IP adres uvedeným ve stejné příručce a vyhněte se SIP ALG, protože narušuje SIP signalizaci. Je třeba se vyhnout mediálnímu provozu přes proxy.

DNS a NTP

Zajistěte správné rozlišení DNS domén a spolehlivé NTP servery pro synchronizaci hodin zařízení pro ověřování a protokolování certifikátů TLS.

Plánování failoveru

Zvažte stávající připojení k datovým sítím od poskytovatelů (MPLS, SD-WAN atd.) a obecně naplánujte přímý přístup k internetu na každém místě v rámci vašeho nasazení. Naplánujte redundantní internetové linky tam, kde je vyžadována vysoká dostupnost. Protože budete využívat cloudové služby, je základním požadavkem spolehlivé připojení k internetu s dostatečnou šířkou pásma. Pokud internetové připojení ve vaší organizaci není obecně spolehlivé, s nízkou latencí a dostatečnou propustností pro upstream i downstream, měli byste tento přechod znovu zvážit.

Přežití lokality

Funkce „přežití“ webu zajišťuje, že vaše firma bude vždy dostupná, a to i v případě výpadku síťového připojení. Služba Site Survivability využívá bránu ve vaší lokální síti k poskytování záložní služby volání do koncových bodů na místě v situacích, kdy dojde k přerušení síťového připojení. Pokud obchodní požadavky vyžadují nepřetržité volání v případě výpadku sítě, zvažte odolnost lokality pomocí lokální brány pro přežití (SGW). Další informace o kontrole odolnosti webu naleznete v článku Ochrana webu pro volání Webex.

Nastavení sjednocené komunikace připojené ke cloudu

Cloud Connected UC (CCUC) je cloudové řešení pro správu a analýzu, které je navrženo tak, aby poskytovalo centralizovaný přehled, správu a přehledy pro nasazení jak v místních (například Unified CM), tak v cloudových (). Funguje jako most mezi tradičními lokálními prostředími a cloudovými službami Cisco a podporuje organizace během celého procesu migrace z platformy .

Během přechodu na hraje CCUC zásadní roli v zefektivnění procesu migrace tím, že usnadňuje sběr komplexních dat ze stávajícího nasazení Unified Communications. CCUC pomáhá s klíčovými přechodovými úkoly, jako je migrace zařízení, funkcí a uživatelských kontaktů, a také automatizace aktualizací firmwaru pro podporované IP telefony. Díky centralizovanému přehledu a správě pomáhá CCUC zajistit plynulejší a efektivnější migraci.

Společnost Cisco důrazně doporučuje, aby byl systém CCUC nasazen v rané fázi přechodu, ideálně před přípravnou fází nebo během ní. To vám umožní získat poznatky a schopnosti potřebné k důkladnému posouzení, inventarizaci a plánování následných migračních aktivit a k zahájení vaší cesty k budoucím hybridním funkcím.

Posouzení současného prostředí

Klíčovou činností při plánování migrace je posouzení aktuálního místního prostředí a nasazení. To poskytuje vhled do toho, jaké potenciální změny mohou být nutné pro úspěšný přechod na . Umožňuje vám také posoudit klíčové prvky platformy ve srovnání se stávajícím on-premise nasazením. Tyto informace můžete použít k identifikaci konkrétních úkolů, které jsou pro přechod nutné, a k identifikaci změn, které chcete provést, abyste splnili své obchodní a technické požadavky a případy užití.

V rámci tohoto úsilí je důležité přezkoumat následující aspekty.

Licence

Pochopení aktuální licenční struktury existujícího nasazení je klíčové při přípravě na migraci na . Proveďte licenční posouzení následujících oblastí vašeho stávajícího on-premise řešení Cisco.

Platforma

Schopnost plně formulovat, co je aktuálně licencováno na vaší základní platformě, bude klíčová při spolupráci s vaším týmem pro správu účtu nebo partnerem na určení nejlepší cesty k flexibilnímu licencování. Licencováno pomocí flexibilního licencování. Další informace o flexibilním licencování naleznete v článku Flexibilní plán spolupráce Cisco.

Uživatelé a zařízení

Určete, jakou kategorii licencí vaši stávající uživatelé a zařízení potřebují. Toto se použije k určení, jaký typ licence je pro uživatele a zařízení vyžadován. Nabízí několik typů licencí, včetně profesionálních a standardních licencí pro uživatele a profesionálních licencí a licencí pro společné prostory pro pracovní prostory. Více informací o licencování zařízení naleznete v datovém listu dostupném na adrese Licencování zařízení.

Místní brána

Pokud je pro tento přechod pro přístup k PSTN vyžadován Cisco Unified Border Element (CUBE), je třeba zvážit i licencování CUBE. Aspekty licencování CUBE jsou popsány dále v tomto dokumentu.

Locations/Sites

Při plánování tohoto přechodu je třeba zvážit počet a typy pracovišť (velká centrální, regionální, pobočková atd.) v rámci vašeho stávajícího nasazení. Úplné pochopení stávajících nasazených lokalit pomůže při strategickém plánování úspěšného přechodu, zejména pokud jde o určení, které lokality migrovat a v jakém pořadí. Při rozhodování o migraci bude zásadní podrobné pochopení požadavků na plán vytáčení (číslování, způsoby vytáčení, třídy omezení atd.), připojení k síti a šířky pásma lokality (internet, WAN, LAN) a přístupu k PSTN (lokální nebo centralizovaný, IP nebo TDM) pro každou lokalitu. Další informace o běžných modelech nasazení a klíčových aspektech naleznete v informacích o modelech nasazení pro spolupráci, které jsou k dispozici v Collaboration SRND.

Dalším důležitým faktorem, který je třeba při přechodu na platformu Windows zvážit, je dostupnost lokality. Platforma Windows má různé funkce, předplatná a zařízení, která jsou k dispozici v závislosti na umístění vašeho nasazení. Více informací o geografické dostupnosti naleznete v části Kde je Webex k dispozici?.

Nakonec je důležité pochopit dopad, který bude mít přechod na další služby pro spolupráci. Na základě cíle tohoto dokumentu se vychází z obecného předpokladu, že pokud mají být zachovány stávající služby pro spolupráci mimo volající pracovní zátěž, očekává se přechod na výše zmíněné hybridní nasazení fáze 1. Mezi příklady služeb pro spolupráci, které mohou vyžadovat hybridní nasazení, patří kontaktní centrum v místních prostorách, které dosud nebylo migrováno do kontaktního centra Webex, a úzká integrace do systémů, jako jsou pagingové systémy a fakturace. Další informace o přechodu dalších úloh a služeb pro spolupráci naleznete v článku Přechody pro spolupráci.

Stávající zásoby devices/clients

Před zahájením přechodu je důležité provést inventuru stávajícího hardwarového a softwarového vybavení. Mít kompletní seznam zařízení types/models, Verze hardwaru, typy operačních systémů softwarových klientů a jejich množství zajistí, že budete moci adekvátně naplánovat přechod zařízení a zmírnit dopad na ta zařízení, která nelze migrovat do cloudového volání. Inventář by měl být použit k určení zařízení, která je třeba převést, a zařízení, která je třeba před přechodem nahradit.

Stolní telefony

U audio a video stolních telefonů jsou podporovány pouze stolní telefony řad 6800, 7800, 8800 a 9800. Toto je podmnožina IP telefonů Cisco, které jsou podporovány systémem . Existují některé modely a verze telefonů 6800, 7800 a 8800, které nelze s některými zařízeními používat. Další informace o podporovaných modelech a verzích hardwaru naleznete v části Podporovaná zařízení pro Webex Calling.

IP telefony Cisco řady 6800 nelze upgradovat z firmwaru Enterprise na firmware Multiplatform (MPP), který je vyžadován pro . Proto musí být všechny telefony 6800 registrované s podnikovým firmwarem nahrazeny modelem 6800 MPP nebo jiným podporovaným modelem telefonu.

IP telefony Cisco řady 7800 a 8800 musí být před přechodem a registrací v systému aktualizovány na firmware Multiplatform Phone (MPP). Chcete-li zjistit, které modely a hardwarové verze 7800 a 8800 podporují firmware MPP, podívejte se na Převod IP telefonů Cisco řady 7800 a 8800 mezi firmwarem Enterprise a MPP.

Modely 8845, 8865 a 8865NR dosáhly konce prodeje a jejich migrace na systém se nedoporučuje.

Starší verze telefonů řady 8800 (8811, 8841, 8851, 8851NR, 8861) se nedoporučují používat s Webex Calling. Telefony s hardwarovou verzí VID 14 nebo starší se zaregistrují, ale mohou mít problémy s výkonem kvůli hardwaru.

Stolní telefony řady 9800 používají systém PhoneOS, který podporuje jak PhoneOS, tak i registraci. Proto lze na tyto telefony přejít bez aktualizace firmwaru.

Všechny ostatní IP telefony bude nutné nahradit telefony řady 6800, 7800, 8800 nebo 9800, které jsou podporovány službou Webex Calling. Další informace o podporovaných IP a stolních telefonech s funkcí naleznete v článku na adrese Podporovaná zařízení pro volání přes Webex.

Koncové body videa

Osobní a místnostní video koncové body, včetně řad Cisco Board, Room a Desk, se mohou nativně registrovat přes SIP k síti. Kterýkoli z těchto koncových bodů, které potřebují přehrávat zvuk and/or Hovory PSTN vyžadují licenci pro volání:

Sdílená zařízení v konferenčních místnostech, prostorách pro jednání atd. vyžadují licenci Professional Workspace nebo Workspace.

Osobní zařízení koncového uživatele vyžaduje profesionální nebo standardní licenci.

Určete, kolik video koncových bodů je registrováno a používá se k uskutečňování zvukových hovorů. Je možné, že některé video koncové body lze použít pouze pro připojení ke schůzkám nebo pro uskutečňování SIP videohovorů. V obou případech je stále nutné migrovat koncové body před vyřazením serverů z provozu, což však pomůže určit, kolik z nich bude potřebovat licence k dalšímu telefonování.

Když jsou videozařízení přesunuta z registrace do , identifikátor URI pro tyto koncové body se změní, protože jsou nyní registrovány v cloudu.

Modely telefonů 8845, 8865 a 8875 jsou osobní videotelefony, které jsou podporovány s technologií .

Měkkých klientů

Je to jediný softwarový klient podporovaný aplikací , na rozdíl od Unified CM, který podporuje aplikaci Webex i Jabber, a je novým výchozím softwarovým klientem pro koncové uživatele.

V závislosti na režimu (režimech) nasazení implementovaném pro Jabber (pouze IM, pouze telefon, and/or plné režimy UC), možná budete muset také zvážit přechod systému Messaging and/or Pracovní zátěž schůzek z Jabberu do . Lze jej nasadit v režimu pouze pro telefon, pokud bude používán pouze jako klient pro volání, nebo jej lze nasadit jako plnou sadu Webex Suite, pokud jsou potřeba další úlohy, např. Webex Messaging and/or Webex Meetings se převádí do aplikace s možností volání.

Vylepšuje uživatelský zážitek tím, že poskytuje funkce umělé inteligence, jako je audio/video inteligence, přepis hovorů a další. Další informace naleznete v tématu https://www.webex.com/all-new-webex.

Před přesunem uživatelů k vám bude nutné převést jejich Jabber klienty na . Máte dvě možnosti, jak tento přechod dokončit.

Než je převedete na

Když je převedete na .

Pro usnadnění počátečního přechodu na se doporučuje použít možnost 1 a přesunout uživatele na , který nejprve volá. To dává uživatelům čas seznámit se s novou aplikací, zatímco stále používají stávající místní platformu pro volání. Jakmile budete připraveni přesunout uživatele do , nakonfigurujete je pro registraci na platformě pro cloudové volání.

Více informací o těchto dvou možnostech naleznete v článku Migrační cesta – jeden nebo dva kroky?.

Úplný seznam podporovaných zařízení pro naleznete v části Podporovaná zařízení pro Webex Calling.

Ověření způsobilosti zařízení

Jak již bylo zmíněno, podporuje podmnožinu IP telefonů Cisco a pro telefony řady 7800 a 8800 vyžaduje jiný typ firmwaru. Telefony Unified CM používají firmware Enterprise, zatímco telefony používají firmware Multiplatform Phone (MPP). Během fáze přípravy se doporučuje ověřit, které registrované telefony jsou způsobilé k upgradu na firmware MPP. To vám dá čas na výměnu nezpůsobilých telefonů za jeden z podporovaných modelů telefonů nebo na identifikaci alternativního tarifu, například na přesun uživatele pouze do aplikace Webex.

Pro pomoc s určením způsobilosti telefonů má Control Hub vestavěný nástroj s názvem Migrace telefonu do služby Webex Calling. Při použití tohoto nástroje k kontrole způsobilosti zařízení vyberte možnost Migrace Generovat pouze licenci zařízení.

Možnost nástroje Control Hub pro ověření způsobilosti telefonů Unified CM pro Webex Calling

Tato možnost vám umožňuje nahrát soubor CSV s telefony, abyste si mohli ověřit, zda každý telefon splňuje podmínky. Výběrem této možnosti migrace se telefony nepřidají, protože jste stále ve fázi přípravy a ještě na to nejste připraveni. Další informace naleznete zde Migrujte svůj telefon na Webex Calling .

Je možné, že některé telefony se vrátí s Neznámá způsobilost. To je obvykle způsobeno tím, že systém back-endu nedokáže ověřit některé informace o telefonu. U telefonů se stavem Neznámý máte dvě možnosti, jak ověřit, zda jsou způsobilé k upgradu na firmware MPP.

Ručně zkontrolujte každý telefon a ověřte model a verzi hardwaru (PID VID)

7800/8800 štítek telefonu s informacemi o modelu a verzi hardwaru

Použití nástroje pro připravenost IP telefonů Cisco

Stáhněte si nástroj z https://github.com/joemar2/mpp_readiness_check.

Tento nástroj není oficiálním nástrojem společnosti Cisco ani není podporován službou TAC. Má maximální podporu, ale je zdarma k použití.

Tento nástroj musí být spuštěn na počítači, který je umístěn lokálně a má přístup k serverům a IP telefonům. Nabízí možnost povolit webový přístup na IP telefonech, což je doporučené a nutné pro dosažení nejlepších výsledků. Proto by se měl používat mimo pracovní dobu, aby se předešlo narušení provozu koncových uživatelů. Výstupem nástroje je zpráva s uvedením telefonů řady 7800 a 8800, které jsou způsobilé k upgradu na firmware MPP. Protože má přímý přístup k telefonu, může ověřit Neznámá zařízení, která byla nahlášena z nástroje Control Hub.

Zpráva o připravenosti nástroje Cisco IP Phone

Uživatelé

Jedním z nejdůležitějších kroků přípravy pro zajištění úspěšné migrace je správné zřizování uživatelů. I v případě, že provádíte postupnou migraci, je nutné řádně naplánovat migraci pro všechny uživatele. Uživatelé musí být zřízeni pro některou z následujících možností:

Nasazení s voláním

Nasazení pomocí

Konfigurace služeb pro uživatele

Umožnit vyhledávání uživatelů v adresáři (klikni a zavolej, kontaktní informace uživatele, vyhledávání v telefonním seznamu).

Doporučuje se zřídit všechny uživatele před zahájením projektu nebo na jeho začátku. To zahrnuje uživatele, kteří stále používají Unified CM pro volací platformu nezávislou na jejich volacím zařízení (IP telefon, Jabber atd.). Jak uživatelé migrují do (and/or ) aktualizujete jim licence, abyste povolili služby, které potřebují. Zřízením všech podnikových uživatelů volajících před zahájením přechodu umožňujete uživateli, který přešel na nebo , vyhledat v adresáři podnikového uživatele volajícího, který je stále na Jabberu. and/or na . Díky tomu mohou převedení uživatelé najít kontaktní informace jakéhokoli jiného uživatele a zavolat mu pomocí vyhledávání v adresáři.

Obrázek vyhledávání v adresáři ukazuje příklad uživatele, který hledá jiného uživatele. Výsledky vyhledávání zobrazují kontaktní informace uživatele a mohou se týkat uživatele, který stále používá Jabber, nebo uživatele, který na Jabber přešel. and/or .

Vyhledávání v adresáři aplikací Webex

Dále určete, kteří ze stávajících uživatelů volajících v místní síti budou převedeni na . Pokud budou převedeni všichni uživatelé nebo jejich velký počet, doporučuje se přesouvat uživatele ve skupinách, aby se zajistilo, že projektový tým, IT pracovníci a podpůrný personál budou schopni zvládnout přechod a případné problémy. Měli byste si také vyhradit čas na poskytnutí úvodních informací a školení, abyste uživatele na tento přechod připravili. Seskupování uživatelů při přechodu lze provést na základě různých kritérií, včetně umístění nebo pracoviště, ke kterému jsou uživatelé přiřazeni, oddělení uživatelů nebo dokonce typů uživatelů (znalostní pracovníci, vedoucí pracovníci, mobilní pracovníci atd.).

Například pokud jsou uživatelé v nasazení rozděleni do tří hlavních lokalit: New York (NYC), San Francisco (SFC) a Research Triangle Park (RTP), může plán přechodu uživatelů vypadat podobně jako plán uvedený v tabulce Plán přechodu uživatelů podle lokalit.
Tabulka 4. Plán přechodu uživatelů podle webu
Uživatelský web / umístění Informace a školení před přechodem Přechodné období Podpora po přechodu
New York (1 525 uživatelů) Týden od 1. dubna 15. dubna – 27. dubna Týden od 29. dubna
SFO (1 600 uživatelů) Týden od 6. května 20. května – 31. května Týden od 3. června
RTP (1 275 uživatelů) Týden od 3. června 17. června – 28. června Týden od 1. července

Dalším důležitým faktorem je společný přechod uživatelů, kteří jsou navzájem závislí. To může zahrnovat, ale není omezeno na následující:

Monitorování BLF

Stejný lov pilot/group

Sdílené linky

Součást stejné skupiny pro vyzvednutí hovoru

Používání stejných čísel pro parkování hovorů

Interkom

Admin/Exec.

Můžete si prohlédnout konfiguraci (GUI nebo export) nebo použít nástroj Migration Insights, který vám pomůže identifikovat skupiny uživatelů s těmito závislostmi.

Připojení k síti PSTN

k PSTN se lze připojit třemi způsoby: Volací tarify Cisco, Cloud Connect for (dříve Cloud Connected PSTN) a místní PSTN (lokální brána). Jedno umístění, jak je definováno v tomto dokumentu, však lze přiřadit pouze k jedné možnosti PSTN.

Místní PSTN s lokální bránou (LGW) je nezbytnou součástí strategie přechodu. Zajišťuje propojení mezi místním nasazením and/or PSTN a platforma podporují jak Cisco, tak i certifikované hraniční řadiče relací (SBC) třetích stran, které lze použít jako lokální bránu. Nejnovější seznam podporovaných SBC naleznete v článku Seznam podporovaných SBC.

podporuje až 250 souběžných volání z jedné lokální brány založené na registraci a více než 250 souběžných volání z jedné lokální brány založené na certifikátu. Lokální brány založené na certifikátech mohou podporovat až 6500 souběžných hovorů, ale to závisí na typu připojení, které musí lokální brána splňovat (Over-the-Top vs. interconnect peering), a na modelu SBC, na kterém je lokální brána nasazena. Tato omezení jsou v podstatě výchozím limitem počtu pro volání přes PSTN přes lokální bránu i pro volání mezi lokalitami mezi koncovými body . Více informací naleznete v části Začínáme s lokální bránou.

Všechna volání překračující tento limit jsou odmítnuta s chybou 403 Forbidden. Příkaz show call active voice lze spustit na lokální bráně v libovolné instanci a zjistit tak celkový počet aktivních hovorů.

Špatné síťové podmínky mezi lokální bránou a přístupovým SBC mohou omezit výkon signalizačního připojení, což vede k ještě nižšímu limitu souběžných volání. Jednosměrná latence mezi lokální bránou a datovým centrem by neměla překročit 100 ms a jitter by měl být menší než 10 ms, zatímco ztráta paketů by měla být menší než 0,5. %.

Funkce & využití funkcí

Při posuzování aktuálního prostředí je důležité identifikovat a zkontrolovat, které funkce jsou nakonfigurovány. Kromě toho je důležité porozumět použití funkcí, abyste mohli (znovu) definovat své obchodní a technické požadavky pro vaše nasazení.

Chcete-li zjistit, které funkce jsou nakonfigurovány, analyzujte konfiguraci. Toto jsou všechna statická data, která se nastavují při konfiguraci funkce nebo nastavení v systému. K dokončení této analýzy lze použít následující možnosti:

Zkontrolujte konfiguraci v grafickém uživatelském rozhraní administrátora

export konfigurace -- hromadný export nebo AXL

nástroj pro analýzu migrace (doporučeno)

Nástroje partnerů třetích stran od Cisco (doporučeno).

Pro efektivní analýzu využití funkcí je nezbytné zkoumat dynamická systémová data, jako je využití, registrace a aktivita volání. Různé analytické nástroje a dashboardy poskytují přehled o těchto metrikách a umožňují komplexní pochopení výkonu a kapacity systému, což podporuje informované rozhodování během migrace a optimalizace. K provedení tohoto typu analýzy lze použít následující možnosti:

Kontrola nezpracovaných záznamů CDR

Kontrola dat Unified CM RTMT

Nástroj pro analýzu migrace s využitím dat CDR

Recenze analytických nástrojů pro sjednocenou komunikaci připojených ke cloudu v

Hlasitost hovorů

Registrované koncové body

(CAC) lokality

Využití kufru.

Nástroje partnerů třetích stran od společnosti Cisco.

Společnost Cisco doporučuje pro tuto analýzu začít s nástrojem Webex Control Hub Migration Insights. Do nástroje importujete exportní soubor .TAR a soubory Unified CM CDR (volitelné, ale nutné pro analýzu využití funkcí). Nástroj vygeneruje následující zprávy ve formátu CSV, které lze použít k zahájení analýzy:

Tabulka 5. Zprávy generované ze souboru .tar Unified CM
Název sestavy
Popis zprávy
ImportedDataBulk.csv
Všichni uživatelé a zařízení z dat Unified CM
DeviceEligibility.csv
Identifikuje zařízení způsobilá k migraci do systému Webex Calling (IP telefony, zařízení Room OS, ATA a zařízení třetích stran)
DevicePoolNumbers.txt
Seznam všech čísel v daném fondu zařízení
HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv
Podrobnosti o zařízeních a uživatelích, kteří by měli být migrováni společně na základě sdílených linek, pilotního programu Hunt, fronty hovorů, parkování hovorů a konfigurace skupiny pro vyzvednutí hovoru
HuntGroupMigrationInsight.csv
Podrobné informace o přiřazených linkách vyhledávání, skupinách linek a přidružených agentech
SharedlineGroupMigrationReport.csv
Přehled sdílení telefonních čísel (čísla v adresáři) mezi uživateli

Tabulka 6. Zprávy generované ze souborů Unified CM .tar a CDR.gzip
Název sestavy
Popis zprávy
FeatureUsageBasedDeviceEligibilityReport.csv
Informace o způsobilosti migrace zařízení na základě používání funkcí
FeatureUsageWithLastUsageDateReport.csv
Počet použití pro počet volání pilotních funkcí Hunt a front volání spolu s datem posledního použití.
UserWorkspaceLastUsage.csv
Datum posledního použití pro uživatele a pracovní prostory pro softwarové klienty i hardwarové telefony
DIDUsageReport.csv
Použití DID pro přiřazené i nepřiřazené DID

Další podrobnosti o přehledech Migration Insights naleznete v článku Migration Insights.

Pokud po přečtení informací v přehledech Migration Insights potřebujete další informace o funkcích a použití, společnost Cisco doporučuje zvážit použití migračních nástrojů od partnerů třetích stran. and/or pro kontrolu konfigurací v grafickém rozhraní nebo v datech exportu konfigurace.

Integrace Cisco: Unity Connection UCCX UCCE

Hlasová schránka je nedílnou součástí nabídky a je nativně integrována do řešení. Nelze ji integrovat s řešením hlasové schránky založeným na premise, jako je Unity Connection nebo Unity Connection Express. Dále neexistuje žádný nativní způsob, jak migrovat stávající hlasové zprávy nebo pozdravy z připojení Unity do nativní hlasové služby dostupné v rozhraní . Některé migrační nástroje partnerů třetích stran společnosti Cisco mají funkce pro migraci některých z těchto dat. Další informace o hlasové schránce pro naleznete v článku Konfigurace a správa nastavení hlasové schránky pro uživatele služby Webex Calling.

podporuje také sdílené hlasové a faxové schránky. Další informace naleznete v článku Správa sdílené hlasové schránky a schránky příchozích faxů pro Webex Calling.

má vestavěnou funkci automatického operátora, která je součástí základní platformy. Tato funkce umožňuje přechod obslužných rutin hovorů a funkcí automatického operátora vašeho Unity Connection. Nástroj Control Hub Migrace funkcí z Unified CM podporuje migraci konfigurací Unity Connection do automatických operátorů. Další informace o používání tohoto nástroje naleznete v části Migrace zařízení a funkcí z Unified CM do Webex Calling.

Nahrávání hovorů

zahrnuje dvě možnosti nahrávání hovorů bez dalších poplatků.

Nahrávání hovorů Webex

Nahrávání Dubber Go (partnerská nabídka) – integrace mezi aplikací Dubber a službou Dubber, kde jsou všechna nahraná média bezpečně uložena v cloudu.

zahrnuté možnosti nahrávání tabulka zdůrazňuje některé klíčové funkce dvou možností nahrávání hovorů, které jsou k dispozici bez dalších poplatků.

Tabulka 7. zahrnuté možnosti nahrávání
Webex Dubber Go

K dispozici všem uživatelům K dispozici všem uživatelům

Neomezené nahrávky Neomezené nahrávky

Doba uchovávání 1 rok* 30denní doba uchovávání

100 GB úložiště na organizaci -

Pracovníci dodržování předpisů mají přístup k nahrávkám hovorů a mohou je spravovat -

API pro správu nahrávek -

Administrátoři mohou konfigurovat a spravovat přístup uživatelů k nahrávkám hovorů
Uživatelé si mohou spravovat vlastní nahrávky pomocí User Hubu. and/or aplikace Webex.
Pouze uživatelé mají přístup k nahrávkám a mohou je spravovat
Z jejich dubberského portálu.

Pokud vaše organizace vyžaduje další funkce nahrávání, jako je nahrávání hovorů o dodržování předpisů, delší doby uchovávání, více úložiště, analýzu umělou inteligencí, and/or přístup správce, placené nabídky nebo doplňky existují jak od společnosti Cisco, tak od poskytovatelů nahrávání třetích stran. Další informace o poskytovatelích nahrávání, konfiguracích a doplňkových partnerských službách naleznete v části Správa nahrávání hovorů pro Webex Calling.

Integrace třetích stran

podporuje řadu integrací^třetích stran, včetně, ale nikoli výhradně, SBC pro lokální brány, IP telefony, interkomové telefony, Speaker/Pagers, ATA atd. Kromě těchto zařízení^třetích stran podporuje Webex Calling různá řešení^třetích stran pro zákaznickou podporu, analýzy, nahrávání, fakturaci atd. Další informace o řešeních třetích stran naleznete v Centru aplikací Webex.

Tabulka 2. Výpočty šířky pásma pro typy hovorů Webex Calling
Typy hovorů	Kodek - šířka pásma	Výpočty šířky pásma
/ Stolní telefon ->	OPUS - 70 kb/s	Počet souběžných hovorů * 70 kb/s = Požadovaná propustnost sítě
/ Stolní telefon -> Stolní telefon	OPUS – 70 kb/s	Počet souběžných hovorů * 70 kb/s = Požadovaná propustnost sítě
/ Stolní telefon -> PSTN přes LGW	G.711 – 80 kb/s	Počet souběžných hovorů * 80 kb/s = Požadovaná propustnost sítě
/ Stolní telefon -> PSTN přes cloudovou PSTN (např. volací tarif Cisco)	G.711 – 80 kb/s	Počet souběžných hovorů * 80 kb/s = Požadovaná propustnost sítě
/ Stolní telefon -> Podnik přes LGW	G.722 – 80 kb/s	Počet souběžných hovorů * 80 kb/s = Požadovaná propustnost sítě
/ Stolní telefon -> hlasová schránka	OPUS – 70 kb/s	Počet souběžných hovorů * 70 kb/s = Požadovaná propustnost sítě

Tabulka 3. Příklady výpočtu šířky pásma pro volání ve Webexu
Typy hovorů	Počet souběžných hovorů	Celková šířka pásma
Aplikace Webex / Stolní telefon → Aplikace Webex	15	2 * 15 * 70 kb/s = 2 100 kb/s
Aplikace Webex / Stacionární telefon → Stacionární telefon	15	2 * 15 * 70 kb/s = 2 100 kb/s
Aplikace Webex / Pevná linka → PSTN přes LGW	50	2 * 50 * 80 kb/s = 8 000 kb/s
Aplikace Webex / Stolní telefon → PSTN přes Cloud Connect pro volání přes Webex	0	0 * 80 kb/s
Aplikace Webex / Pevná linka → Podnik přes LGW	15	2 * 15 * 80 kb/s = 2 400 kb/s
Aplikace Webex / Stacionární telefon → Webex Calling Hlasová schránka	5	5 * 70 kb/s = 350 kb/s
Celkový počet hovorů / Šířka pásma	100 hovorů	14 950 kb/s / 14,95 Mb/s

Tabulka 4. Plán přechodu uživatelů podle webu
Uživatelský web / umístění	Informace a školení před přechodem	Přechodné období	Podpora po přechodu
New York (1 525 uživatelů)	Týden od 1. dubna	15. dubna – 27. dubna	Týden od 29. dubna
SFO (1 600 uživatelů)	Týden od 6. května	20. května – 31. května	Týden od 3. června
RTP (1 275 uživatelů)	Týden od 3. června	17. června – 28. června	Týden od 1. července

Tabulka 5. Zprávy generované ze souboru .tar Unified CM
Název sestavy Popis zprávy
ImportedDataBulk.csv Všichni uživatelé a zařízení z dat Unified CM
DeviceEligibility.csv Identifikuje zařízení způsobilá k migraci do systému Webex Calling (IP telefony, zařízení Room OS, ATA a zařízení třetích stran)
DevicePoolNumbers.txt Seznam všech čísel v daném fondu zařízení
HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv Podrobnosti o zařízeních a uživatelích, kteří by měli být migrováni společně na základě sdílených linek, pilotního programu Hunt, fronty hovorů, parkování hovorů a konfigurace skupiny pro vyzvednutí hovoru
HuntGroupMigrationInsight.csv Podrobné informace o přiřazených linkách vyhledávání, skupinách linek a přidružených agentech
SharedlineGroupMigrationReport.csv Přehled sdílení telefonních čísel (čísla v adresáři) mezi uživateli

Tabulka 6. Zprávy generované ze souborů Unified CM .tar a CDR.gzip
Název sestavy Popis zprávy
FeatureUsageBasedDeviceEligibilityReport.csv Informace o způsobilosti migrace zařízení na základě používání funkcí
FeatureUsageWithLastUsageDateReport.csv Počet použití pro počet volání pilotních funkcí Hunt a front volání spolu s datem posledního použití.
UserWorkspaceLastUsage.csv Datum posledního použití pro uživatele a pracovní prostory pro softwarové klienty i hardwarové telefony
DIDUsageReport.csv Použití DID pro přiřazené i nepřiřazené DID

Tabulka 7. zahrnuté možnosti nahrávání
Webex	Dubber Go
K dispozici všem uživatelům	K dispozici všem uživatelům
Neomezené nahrávky	Neomezené nahrávky
Doba uchovávání 1 rok*	30denní doba uchovávání
100 GB úložiště na organizaci	-
Pracovníci dodržování předpisů mají přístup k nahrávkám hovorů a mohou je spravovat	-
API pro správu nahrávek	-
Administrátoři mohou konfigurovat a spravovat přístup uživatelů k nahrávkám hovorů Uživatelé si mohou spravovat vlastní nahrávky pomocí User Hubu. and/or aplikace Webex.	Pouze uživatelé mají přístup k nahrávkám a mohou je spravovat Z jejich dubberského portálu.

Plán

Plán projektu na vysoké úrovni

Migrační cesta – jeden nebo dva kroky?

Možnost 1: Migrace uživatelů v jednom kroku

Možnost 2: Dvoukroková migrace uživatelů

1. krok

2. krok

Plán projektu na vysoké úrovni

Při vývoji obecného projektového plánu pro migraci z platformy .NET na platformu .NET je nezbytné stanovit jasné fáze a milníky, které odpovídají jak obchodním cílům, tak technickým požadavkům. Plán by měl začít komplexní fází posouzení, včetně shromáždění podrobných technických a obchodních požadavků, identifikace zainteresovaných stran a definování kritérií úspěchu. Mezi klíčové aspekty patří alokace zdrojů, odhad časového harmonogramu, řízení rizik a komunikační strategie, aby se zajistilo, že všechny strany budou informovány a zapojeny po celou dobu migrace. Plán by měl navíc zahrnovat ověřovací kontrolní body, jako je pilotní testování a postupné zavádění, aby se minimalizovalo narušení a umožnily úpravy na základě zpětné vazby.

Příklady prvků, které je třeba zahrnout do projektového plánu, jsou:

Definování rozsahu migrace (např. kteří uživatelé, zařízení a funkce budou převedeny)

Plánování školení pro koncové uživatele a týmy podpory

Koordinace hodnocení připravenosti sítě a

Plánování přechodných aktivit s záložními možnostmi. Důležité je také integrovat kontroly dodržování předpisů a zabezpečení, stejně jako fáze podpory a optimalizace po migraci.

Strukturováním projektového plánu s ohledem na tyto aspekty mohou organizace lépe zvládat složitost, snižovat rizika a dosáhnout plynulejšího přechodu na .

Migrační cesta – jeden nebo dva kroky?

vyžaduje, aby uživatelé pro volání používali softwarového klienta. Pokud tedy nějací uživatelé stále používají , máte dvě možnosti, kdy je můžete do . Můžete provést buď jednokrokovou migraci uživatelů, nebo dvoukrokovou migraci uživatelů.

Možnost 1: Migrace uživatelů v jednom kroku

V rámci jednokrokové migrace uživatelé přecházejí z platformy do platformy současně s přechodem z platformy Unified CM do platformy . Tato možnost je obvykle určena pro zákazníky s malým počtem uživatelů k migraci a umožňuje přesun softwarového klienta i volací služby uživatele současně. Obrázek Volání uživatele, softwarový klient & telefon migruje současně do níže zdůrazňuje tento typ migrace. S touto možností bude mít uživatel najednou dokončeno vše následující:

Volací služby přesunuty z na

Telefonní čísla a linky přesunuty z do

Soft klient přešel z Jabberu na - zaregistruje se do

Registrace telefonu přesunuta z do .

Volací služba uživatele, softwarový klient & telefon migruje ve stejnou dobu

Může se stále jednat o fázovanou migraci, kdy jsou skupiny uživatelů přesouvány v různých časech, ale když je každý uživatel přesunut, probíhá to vše současně.

Možnost 2: Dvoukroková migrace uživatelů

Druhým přístupem je dvoustupňová migrace. V kroku 1 jsou uživatelé převedeni z režimu do režimu , ale zůstávají zapnuti pro volání služeb. Pak jsou v kroku 2 uživatelé přesunuti z Unified CM do . Tato možnost se doporučuje větším zákazníkům, kteří chtějí spravovat změny koncových uživatelů a oddělit změnu softwarového klienta uživatele od změny volající služby. Následující obrázek Migrace softwarového klienta; poté migrace volající služby, softwarový klient & Níže uvedený text zdůrazňuje tento typ migrace z telefonu do Webex Calling.

1. krok

Soft klient přešel z na - zaregistruje se do .

2. krok

Volací služby byly přesunuty z do .

Telefonní čísla a linky byly přesunuty z do .

registrace přesunuta z do .

Registrace telefonu přesunuta z do .

Migrace softwarového klienta; poté migrace volající služby, softwarového klienta & telefon do Webex Calling

Stále se může jednat o fázovanou migraci, kdy jsou skupiny uživatelů v obou krocích přesouvány v různých časech.

Možnost, kterou si vyberete, závisí na tom, jak chcete spravovat přechod uživatelů na a . Doporučuje se postupovat postupně (možnost 2). To vám umožňuje minimalizovat změny koncového uživatele najednou a rozdělit úsilí mezi různé části projektu. Pokud však chcete, aby se uživatelé ovlivnili pouze jednou, je platná i možnost 1.

Při pohledu na doporučenou cestu (možnost 1), mapa přechodu na vysokou úroveň z aplikace Jabber do aplikace Webex obrázek níže ukazuje přechod na vysokou úroveň pro krok 1.

Mapa přechodu na vyšší úrovni z aplikace Jabber do Webex

V tomto kroku jsou uživatelé převedeni z Jabberu na pro všechny své volací služby. Volací platformou je však stále Unified CM a své volací služby zaregistruje u . Jak je vidět na obrázku mapy přechodu z Jabberu do aplikace Webex na vyšší úrovni, místní infrastruktura se nemění a funguje stejně jako Jabber. Jedinou změnou je požadavek na připojení k .

Další informace o tomto přechodu naleznete v části Mapa přechodu z Jabberu na Webex a Průvodce nasazením v části Klient na stránce Přechod spolupráce.

Mapa přechodu na vysoké úrovni z Unified CM do Webex Calling obrázek znázorňuje přechod na vysoké úrovni z do. Toto je krok 2 doporučené cesty.

Mapa přechodu na vyšší úrovni z jednotného CM do Webex Calling

Pokud se rozhodnete použít jednokrokový přístup, platí to také.

V tomto kroku jsou uživatelé rozděleni do skupin. V tomto okamžiku uživatelé začnou používat pro své volací služby, registraci volajících a registraci IP telefonu.

Protože se uživatelé přesouvají ve skupinách, budou podnikoví uživatelé během přechodu rozděleni mezi dvě volací platformy. Fáze 1 na obrázku Mapa přechodu na vyšší úrovni z Unified CM do Webex Calling znázorňuje tento stav. Během této fáze je nutné plánovat, jak spravovat hovory mezi uživateli na obou platformách a jak budou směrovány hovory PSTN. Pokaždé, když je skupina uživatelů převedena na , budou vyžadovány aktualizace dial-planů a směrování hovorů na a lokální bráně (bránách).

Jakmile budou všichni uživatelé, softwaroví klienti a zařízení převedeni do fáze 2, lze veškerou místní infrastrukturu sjednocené komunikace odebrat a vyřadit z provozu.

Navrhnout

Výběr regionu

Pobočky

Síť PSTN

Plán vytáčení

Místní vytáčecí plán v

plán vytáčení

Záznam

1. Výběr poskytovatele nahrávání hovorů

2. Výběr regionu

Tísňové volání

Licence

Ruční přiřazení prostřednictvím

Šablony automatického přiřazení licencí

Hromadné přiřazení pomocí šablony CSV

Přiřazení založené na API

Požadavky na licenci

Zřizování uživatelů

Skupiny uživatelů

Doporučený postup při migraci z na

Návrh uživatelských skupin

Jednotné přihlašování (SSO)

Podpora více IdP

1. Fúze a akvizice

2. Několik nezávislých IT oddělení

3. Různé uživatelské skupiny nebo domény

4. Podpora různých ověřovacích protokolů

5. Vylepšené zabezpečení a dodržování předpisů

6. Zjednodušený uživatelský zážitek

Duo MFA s jednotným přihlašováním pro

Funkce

Automatický operátor

Parkování hovorů

Hromadné zpracování hovorů

Fronta hovorů

Skupina sdružených linek

Provozní režimy

Skupina pagingu

Nahrávky

Dosažitelnost na jednom čísle

Skupina hlasové pošty

Výběr regionu

je k dispozici globálně a je dodáván z redundantních datových center v několika regionech: USA (Dallas, Chicago), Kanada (Vancouver, Toronto), Evropa (Frankfurt, Amsterdam), Spojené království (Londýn, Manchester), Austrálie (Melbourne, Sydney), Japonsko (Tokio, Ósaka), Saúdská Arábie (Rijád, Džidda) a Indie (Bombaj, Čennaí). Mediální PoP poskytují mediální služby pro optimalizaci doby přenosu médií. Například singapurské datové centrum se používá k optimalizaci doby přenosu médií pro zákazníky v asijských zemích, kde by doba přenosu do Austrálie nebo Japonska mohla být neoptimální. Datová centra jsou propojena multigigabitovou a plně redundantní páteřní sítí. Obrázek globálně distribuovaná datová centra ukazuje přehled všech datových center. Nejnovější seznam dostupných datových center naleznete v části Umístění datových center pro Webex Calling.

Globálně distribuovaná datová centra

Každý zákazník je zřízen v jedné z instancí. Veškeré informace o zřizování daného zákazníka jsou uloženy v dané instanci a signalizace SIP všech koncových bodů a lokálních bran zřízených pro daného zákazníka je vázána na instanci, na které je zákazník zřizován. Protože je obtížné změnit počáteční výběr regionu, je důležité zvážit všechny relevantní faktory jako součást rozhodovacího procesu vedoucího k výběru regionu. Aby se předešlo nadměrnému zpoždění při přenosu signálu, je důležité v rané fázi přechodu rozhodnout, která instance by měla být použita. Společnost Cisco doporučuje vybrat instanci, která poskytuje nejkratší dobu přenosu signálu pro největší počet uživatelů v rámci nasazení.

Dostupnost v jednotlivých zemích naleznete v části Kde je Webex k dispozici?.

Pobočky

Pro přípravu na zřizování umístění je třeba shromáždit požadované informace pro všechna cílová umístění migrace. Informace potřebné pro každou lokalitu jsou shrnuty v Informace k zachycení pro každou lokalitu.
Tabulka 1. Informace k zaznamenání pro každou lokalitu
Informace Komentář
Rozsah(y) rozšíření Každá lokalita může mít klapky začínající různými číslicemi. Jedna číslice musí být rezervována pro řídicí číslici pro vytáčení mezi stanicemi (například 8) a jedna pro řídicí číslici pro PSTN (například 9). Žádný rozsah rozšíření nemůže začínat žádnou z těchto dvou číslic.
Všechny rozsahy rozšíření ve všech lokalitách musí mít stejnou délku.
Rozsah(y) DID -
Řídicí číslice PSTN -
Kód webu Všechny kódy lokalit na všech místech musí být jedinečné a mít stejnou délku.
Hlavní číslo Při vytváření umístění je třeba zřídit dva DID. Jedno jako hlavní číslo (například pro přiřazení automatické telefonní službě) a jedno pro portál hlasové schránky.
Pro číslo hlasové schránky zřiďte jedno DID.
Číslo hlasové schránky
Počet licencí Požadované licence podle typu, včetně Standard, Professional, Workspace, Route List, Outbound Calling Plan.
Souběžné hovory v rušné hodině Součet souběžných hovorů mezi zařízeními a mezi zařízeními a lokální bránou (PSTN a hovory do zařízení). Je to nutné k určení požadované šířky pásma pro přístup k internetu.
Země -
Časové pásmo -
Jazyk -
Kontakt (jméno, telefon, e-mail) -
Adresa (ulice, město, stát, PSČ) -
Fyzické umístění pro vyslání koncových bodů záchranných složek Místo, kam lze zařízení odeslat pro tísňová volání, obvykle zahrnuje následující: adresa budovy, adresa budovy + číslo patra, adresa budovy + číslo apartmánu nebo adresa budovy + číslo patra + office/cubical číslo.
Unikátní fyzické umístění v síti pro každé zařízení pro tísňové služby Fyzické umístění v síti pro tísňová volání obvykle zahrnuje následující: přepínač / switchport pro kabelová zařízení, bezdrátové přístupové body (AP) a identifikátory základní sady služeb (BSSID) pro bezdrátově připojená zařízení, and/or místní podsíť(e) IP pro koncová zařízení.

Síť PSTN

Při navrhování nasazení mají zákazníci tři hlavní možnosti připojení k PSTN: Volací plány Cisco (cloudová služba PSTN spravovaná společností Cisco), poskytovatelé cloudově připojené PSTN (CCPP, kde poskytovatelé poskytují služby PSTN prostřednictvím cloudu) a místní PSTN (kde lokální brány připojují podnikovou síť k PSTN). Se zavedením PSTN trunkingu pro hybridní nasazení (další informace naleznete v části PSTN trunking pro hybridní nasazení Webex Calling na adrese PSTN trunking) získávají organizace větší flexibilitu ve svém migračním přístupu. Tato funkce umožňuje zákazníkům přesunout svou PSTN na CCPP na začátku přechodu a zahájit přechod na cloudovou PSTN pro uživatele, přičemž CCPP využívá k zachování služby PSTN pro uživatele, kteří zůstávají u Cisco během postupné migrace.

Tento hybridní přístup umožňuje organizacím přesunout nejprve vybrané skupiny uživatelů do cloudu, aniž by musely okamžitě přepracovat celé své telefonní prostředí. Zavádí to však další složitost a rizika, zejména v souvislosti s přizpůsobením stávající logiky směrování hovorů pro podporu nové architektury. Pečlivé zvážení vyžaduje také interoperabilita se staršími aplikacemi, jako jsou faxové servery, kontaktní centra nebo pagingové systémy. Mezi klíčové technické výzvy může patřit zajištění bezproblémového vyjednávání kodeků mezi koncovými body a signalizace DTMF (Dual-Tone Multi-Frequency) v celém smíšeném prostředí, jakož i ověření kompatibility se specializovanými telefonními funkcemi. Správné plánování a testování jsou nezbytné pro minimalizaci narušení a udržení spolehlivých hlasových služeb v průběhu celého procesu migrace. Důležité jsou také komerční aspekty, protože hybridní trunking vyžaduje licenci na užívání, která je založena na počtu souběžných hovorů mezi místním prostředím a poskytovatelem cloudové PSTN (CCPP).

Organizace se také mohou rozhodnout zachovat si během přechodné fáze své lokální připojení k PSTN. V tomto scénáři lze migraci na CCPP provést dvěma způsoby: jako jednorázové, koordinované přechody pro všechny uživatele a lokality po dokončení migrace, nebo postupně, přičemž migrace PSTN probíhá pro každou lokalitu podle toho, jak jsou uživatelé přesouváni do . Tento přístup může pomoci zefektivnit koexistenci a zachovat kontinuitu starších integrací, ale přináší několik provozních složitostí. Mezi ně patří výzvy související s přenášením čísel, jako je potřeba přesné koordinace objednávek přenášení čísel, potenciální zpoždění a omezení stanovená poskytovateli, jako je například limit počtu souběžných požadavků na přenášení nebo omezení přenášení podmnožin velkých číselných bloků. Organizace musí pečlivě naplánovat svou strategii přechodu na PSTN s ohledem na tyto logistické aspekty, aby se vyhnuly přerušení služeb a zajistily hladký průběh migrace.

Migrace na CCCP na začátku vs. ponechání místní PSTN

Obrázek Migrace na CCCP na začátku vs. ponechání místní PSTN ukazuje dvě výše popsané možnosti migrace do PSTN. Ilustrace vlevo znázorňuje scénář, kdy všichni místní uživatelé a aplikace využívají služby Cloud Connected PSTN prostřednictvím místního kmenového kanálu a lokální brány propojující místní síť s , zatímco ilustrace vpravo znázorňuje scénář, kdy stávající místní PSTN zůstává zachována a uživatelé ve službě Webex Calling využívají místní PSTN prostřednictvím připojení lokální brány mezi místní sítí a . Během přechodu lze lokality přepnout na jiné pomocí cloudově připojené PSTN.

V obou scénářích volání mezi místním prostředím a uživatelem využívají připojení lokální brány. Spojení mezi místními systémy a sítěmi musí být navrženo a dimenzováno odpovídajícím způsobem na základě očekávaného počtu souběžných volání a požadované redundance.

Plán vytáčení

Pro dosažení bezproblémové interoperability mezi migračním obdobím a během něj je nutné vyvinout a implementovat komplexní architekturu dial planu na obou platformách. Tento návrh dvouplatformového dial plánu zajišťuje konzistentní směrování hovorů, převod čísel a transparentnost funkcí, což umožňuje uživatelům v obou systémech komunikovat bez zhoršení služeb nebo narušení uživatelské zkušenosti během fáze koexistence.

Místní vytáčecí plán v

Během přechodu, který umožní koexistenci zařízení registrovaných v Unified CM a v podnikovém dial plánu, je třeba změnit podmínky tak, aby byly splněny alespoň následující požadavky:

+E.164 vytáčení z do

Vytáčení poboček z do (v rámci stanice, ale i mezi stanicemi, pokud jsou rozsahy poboček jedinečné)

Zkrácené vytáčení mezi stanicemi od do

Vynucené vytáčení v síti z adresy do

Zpětné volání z adresáře zmeškaných hovorů na cílové stanice

Volání z PSTN do PSTN, pokud se během přechodu používá místní PSTN pro

Volání PSTN z do, pokud se během přechodu používá trunking PSTN pro hybridní nasazení k poskytování přístupu k PSTN místním uživatelům prostřednictvím Cloud Connect pro

Vynucené připojení k síti z do

Volba pobočky z do (mezi stanicemi).

Pokud některý z výše uvedených způsobů vytáčení nebyl před přechodem podporován, například neexistuje zkrácený způsob vytáčení mezi pracovišti, pak jej během přechodu nutně není nutné zavádět.

Obrázek Nejlepší postupy pro vytáčecí plán ukazuje nejlepší postupy pro vytáčecí plán, jak je popsáno v Preferovaná architektura pro Cisco Collaboration 12.x Enterprise On-Premises Deployments, CVD. Mezi klíčové charakteristiky tohoto přístupu patří:

Jeden oddíl pro +E.164 telefonní čísla

Směrování jádra založené na +E.164 vzory tras

Normalizace všech zvyků vytáčení +E.164 použití překladových vzorů

Použití dědičnosti vyhledávacího prostoru volání vzorů překladu (volba Použít vyhledávací prostor volání původce nastavená u vzorů překladu).

Nejlepší postupy pro vytáčení

Například vytáčení PSTN (9+1+10D) ze zařízení v SJC s vyhrazeným vyhledávacím prostorem pro volání linky bude SJCInternational nejprve nalezeno porovnání s 9.1[2-9]XX[2-9]XXXXXX překladový vzor, který normalizuje číslo volané strany na +E.164. Sekundární vyhledávání pak znovu použije stejný vyhledávací prostor SJCInternational (volá dědičnost vyhledávacího prostoru) a +E.164-digit řetězec bude buď nalezen shodný s +E.164 číslo adresáře v oddílu DN nebo jedním ze vzorů tras PSTN v oddílu USPSTNNational nebo SJCPSTNNocal. Zkrácené způsoby vytáčení v rámci lokality a mezi lokalitami jsou implementovány překlady v oddílech ESN a SJCtoE164. Zatímco oddíl ESN je globální oddíl (přístupný pro telefony ve všech lokalitách), oddíl SJCTOE164 je přístupný pouze uživatelům v lokalitě SJC. Toto za předpokladu překrývajících se rozsahů rozšíření.

Prvním krokem k povolení volání z adresy „do“ je zajistit, aby +E.164 Cíle jsou směrovány odpovídajícím způsobem. Toho lze dosáhnout přidáním oddílu do dial planu, přidáním +E.164 vzory tras pro všechny cíle do daného oddílu a nakonec přidání oddílu do všech volajících vyhledávacích prostorů reprezentujících třídy služeb, které musí být schopny dosáhnout . Vytvoření vyhrazeného oddílu je nutné pro umožnění vytvoření diferencované třídy služeb pro volání pocházející z . Aby se předešlo smyčkám hovorů, neměl by mít vyhledávací prostor příchozích volání na kmenové lince z lokální brány přístup k oddílu.

+E.164 směrování do služby Webex Calling

Jak je znázorněno na obrázku +E.164 směrování do Webex Calling, aby bylo možné směrovat z místa do místa s +E.164 Rozsah DID +1 221 555 2XXX a kód lokality 121, což je odpovídající vzorec naléhavé trasy +E.164 Do oddílu je třeba přidat rozsah.

Pokud není vyžadován výběr lokální brány specifické pro dané místo, pak namísto použití seznamu tras s lokální skupinou tras jako cílem pro vzory tras odkazující na jednu skupinu tras lze zřídit s lokální branou jako jediným členem a poté vzory tras odkazovat na jeden seznam tras s touto jednou skupinou tras jako jediným záznamem.

Pro povolení zkrácené volby mezi lokalitami se do oddílu přidá požadovaný vzor směrování 8121.2XXX. Pro lokality, které mají být převedeny na vzorec normalizace vytáčení 8121.2XXX, který normalizuje vytáčení ESN na +E.164 již může existovat v oddílu ESN. V takovém případě se zdá, že 8121.2XXX je redundantní, ale jakmile jsou všechna DN příslušného umístění migrována na 8121.2XXX, lze odstranit vzor pro normalizační překlad vytáčení a poté vzor trasy 8121.2XXX umožní vytáčení ESN i pro uživatele pouze s pobočkou v daném rozsahu.

Díky těmto změnám v plánu vytáčení lze hovory na danou lokalitu uskutečňovat nejen vytáčením zkrácených čísel mezi stanicemi a +E.164. Mezinárodní a národní vytáčení PSTN je také možné, protože tyto zvyky vytáčení jsou nejprve normalizovány +E.164 prostřednictvím již existujících vzorů překladu normalizace vytáčení a poté směrován porovnáním +E.164 vzor trasy v oddílu.

Ten/Ta/To +E.164 Porovnávání vzorů tras v rozsahu DID umístění lze zajistit, i když jsou všechna DID stále hostována na . Algoritmus pro porovnávání vzorů s nejlepší shodou zajišťuje, že když je vytočeno číslo hostované na +E.164 Číslo adresáře zřízené na je lepší shoda než zástupný znak +E.164 vzor trasy ukazující na , aby se volání prodloužila na linku na a nebyla odeslána na .

plán vytáčení

Každý uživatel má zřízeno rozšíření. and/or A +E.164 telefonní číslo. Délka prodloužení je pevně daná globální hodnota: Všechna rozšíření v nasazení mají stejnou délku. Vytáčení poboček lze použít mezi uživateli jak v rámci jedné lokality, tak i mezi lokalitami. Zkrácené vytáčení mezi stanicemi (druhý případ) funguje pouze v případě, že je vytáčená klapka jedinečná.

Pokud je vyžadována zkrácená volba mezi lokalitami, ale dochází k překrývání mezi pobočkami přiřazenými na různých místech, je třeba vytvořit číslovací plán specifický pro daný podnik tak, že se před pobočky přidá přístupový kód (předvolba lokality). Další informace naleznete v článku Preferovaná architektura pro Cisco Collaboration 15 v místních nasazeních, přehled návrhu dostupném na adrese Preferované architektury Cisco Collaboration.

Délka pobočky, chování při vytáčení mezi lokalitami, délka prefixu pro vytáčení mezi lokalitami a řídicí číslice v routerovém prefixu pro vytáčení mezi lokalitami se konfigurují v nastavení volacích služeb v :

Délka prefixu směrování umístění: Délka prefixu včetně číslice řízení. Vyžaduje se pouze v případě, že je třeba zavést podnikový číslovací plán jako alternativní zkrácený podnikový mezilokační vytáčecí plán.

Řídicí číslice v předponě směrování: Řídicí číslice pro zkrácené vytáčení mezi podniky. Je třeba se vyhnout překrývání první číslice libovolné polohy a číslic odchozího volání polohy. Vyžaduje se pouze v případě, že je třeba zavést podnikový číslovací plán jako alternativní zkrácený podnikový mezilokační vytáčecí plán.

Délka vnitřního prodloužení: Standardní délka prodloužení. Může mít libovolnou hodnotu mezi dvěma a deseti.
Pokud je z místního řízení volání vyžadováno vytáčení čísla klapky nebo vytáčení pomocí podnikových čísel (řídicí kód, kód lokality, klapka) a místní řízení volání odesílá klapku jako ID volajícího, nezapomeňte také nastavit parametr Maximální délka neznámé klapky v části Směrování volání mezi lokalitami, abyste zajistili, že odchozí volání z místního řízení volání mohou být správně klasifikována jako místní volání.

Povolit vytáčení poboček mezi lokalitami: Přepnout na enable/disable vytáčení poboček mezi lokalitami. Tato možnost by měla být povolena pouze v případě, že všechny linky v organizaci jsou jedinečné. Pokud je tato možnost zakázána, je nutné mezi lokalitami vytáčet čísla významná pro podnik (řídicí kód, kód lokality, klapku) nebo telefonní čísla.

První tři parametry se používají hlavně k vytvoření plánu vytáčení pro telefony, aby se minimalizovaly mezičíslicové časové limity při vytáčení se zvednutým sluchátkem. Odchylky od těchto globálních nastavení jsou stále možné (příklad – lze zřídit pobočky s jinou délkou), ale v Control Hubu se zobrazí varovná zpráva a vytáčení z telefonů může vyžadovat blokové vytáčení, aby se předešlo konfliktům v rámci přednastaveného plánu vytáčení.

Tabulka Příklad číslování podniků ukazuje příklad tří lokalit, kde jsou rozsahy klapek dvou lokalit, NYC a RTP, shodné. Zavedení podnikového schématu číslování s číslicí pro řízení mezi pracovišti 8, následovanou třímístným kódem pracoviště a čtyřmístnou příponou, vytváří nepřekrývající se zkrácený způsob vytáčení mezi pracovišti.

Tabulka 2. Příklad číslování podniku
Web Rozsah rozšíření Kód webu Řada Enterprise

New York 2XXX 202 8 202 2XXX

SFO 3XXX 203 8 203 3XXX

RTP 2XXX 204 8 204 2XXX

Aby byl přechod hladký, měly by být návyky vytáčení pro uživatele před a po přechodu ideálně stejné. Pro přípravu na přechod je třeba pro každou lokalitu zdokumentovat rozsahy DID a rozsahy poboček (nebo zkrácené zvyklosti vytáčení v rámci lokality). Na základě těchto informací je pak třeba vybrat číslici řízení mezi pracovišti.

Tabulka Rozsahy prodloužení s pevnou délkou ukazuje příklad tří umístění a rozsahů prodloužení s pevnou délkou. Protože je třeba se vyhnout překrývajícím se způsobům vytáčení, je důležité zajistit, aby se u žádného rozsahu poboček první číslice rozsahu neshodovala s řídicí číslicí pro zkrácenou volbu mezi stanicemi. Pokud je například jako řídící číslice pro vytáčení mezi stanicemi vybrána 8, pak žádný rozsah poboček v žádné stanici nemůže začínat na 8. Obvykle se čísla poboček v daném místě shodují s posledními několika číslicemi DID přiřazených tomuto místu. Aby se předešlo konfliktům, lze změnit první číslici přípony. Pokud například DID v +1 Pokud se v dané lokalitě používá rozsah 408 555 8XXX, pak místo použití rozsahu poboček 8XXX lze pro pobočky v dané lokalitě použít rozsah 7XXX.

Tabulka 3. Rozsahy prodloužení s pevnou délkou
Web Rozsah rozšíření Rozšíření Kód webu Řada Enterprise

New York 2XXX 2XXX 202 8 202 2XXX

SFO 8XXX 7XXX 203 8 203 7XXX

RTP 1XX 11XX 204 8 204 11XX

Sedmimístné číselné řetězce vytáčené na zařízení používajícím americký telefonní plán se překrývají se sedmimístným vzorem pro místní vytáčení v přednastaveném americkém telefonním plánu. Aby se zabránilo překrývání mezi jakýmikoli zvyklostmi vytáčení v síti a mimo síť (PSTN), lze v daném místě použít povinný venkovní přístupový kód. Pokud se stávající schéma číslování v podniku a odpovídající zkrácená mezistátní volba překrývá se vzory v celostátní volbě, lze je během přechodu na schéma číslování, aby se předešlo překrývání, změnit na delší nebo kratší formu. Nejjednodušší způsob, jak toho dosáhnout, je přidat do schématu číslování další číslici pro doplnění. Nové, delší schéma vytáčení mezi pracovišti musí přijmout pouze uživatelé, kteří již migrovali na . Uživatelé, kteří jsou stále online, mohou i nadále vytáčet sedmimístné číslo. Podnikový vytáčecí plán v tomto případě musí zajistit, aby se zkrácená sedmimístná volba z Unified CM transformovala buď na +E.164 nebo do zkráceného formátu vytáčení nasazeného na . To je třeba provést před odesláním volání na lokální bránu.

Příklad tohoto přečíslování ukazuje tabulka Přechod na sedmimístné vytáčení. V tomto příkladu zkrácená mezistátní volba používá řídící číslici 8, následovanou dvoumístným předvolbou stanice a čtyřmístnou klapkou. Aby se zabránilo sedmimístnému zkrácenému vytáčení mezi stanicemi pro lokality na , lze kódy stanic snadno změnit na tři číslice přidáním libovolné doplňující číslice (v tomto příkladu8 ) před dvoumístné kódy stanic použitých v , takže vytáčení mezi stanicemi z telefonů používá řídící číslici 8 následovanou doplňující číslicí 8, starý dvoumístný kód stanice a čtyřmístnou příponu. Uživatelé na si nemusí pamatovat nové předvolby stanic; stačí si pamatovat, že pro vytáčení mezi stanicemi mají jako předponu použít 88 místo 8 na .

Tabulka 4. Přechod na sedmimístné vytáčení

Web Rozšíření Kód webu Řada Enterprise óda webu Podnikový ange

New York 2XXX 22 8 22 2XXX 822 8 822 2XXX

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

RTP 1XXX 24 8 24 11XX 824 8 824 11XX

V situaci s různými formáty podnikových čísel a pokud jsou podniková čísla prezentována jako informace o volající straně pro hovory od „do“ (například – hovory ze zařízení bez DID), je důležité implementovat také mapování mezi různými formáty čísel pro informace o volající straně, aby se zajistilo fungování zpětného volání. Tohoto mapování lze dosáhnout použitím transformačního vzoru volající strany na kmenové lince mezi řídicí jednotkou a lokální bránou.

Záznam

Dobře navržené řešení pro nahrávání hovorů vyžaduje pečlivé zvážení několika klíčových konstrukčních prvků, aby se zajistilo, že bude v souladu s organizačními cíli, regulačními požadavky a technickými omezeními. Dvě z nejdůležitějších rozhodnutí zahrnují výběr poskytovatele a výběr regionu, přičemž obojí může být nutné globálně přizpůsobit a v konkrétních lokalitách přepsat na základě obchodních potřeb.

1. Výběr poskytovatele nahrávání hovorů

Výběr vhodného poskytovatele nahrávání hovorů je zásadní pro splnění obchodních cílů a zajištění sladění funkcí v celé organizaci:

Výběr globálního poskytovatele: Organizace obvykle určí primárního poskytovatele nahrávání hovorů na globální úrovni, čímž zajistí konzistenci v sadě funkcí, dodržování předpisů a podpoře na všech místech.

Přepsání na základě polohy: V situacích, kdy konkrétní lokality nebo regiony mají jedinečné obchodní potřeby nebo regulační požadavky, může být nutné přepsat globální výběr poskytovatele a pro tato místa určit alternativní poskytovatele. Tato flexibilita podporuje různé požadavky na dodržování předpisů a místní provozní potřeby.

Obchodní požadavky: Výběr poskytovatele by měl být řízen posouzením obchodních faktorů, jako je dodržování předpisů (příklad – MiFID II, HIPAA), zajištění kvality, řešení sporů nebo potřeby školení.

Dostupnost funkcí: Poskytovatelé by měli být hodnoceni na základě jejich schopnosti poskytovat požadované funkce, jako je monitorování v reálném čase, možnosti vyhledávání a přehrávání, šifrování, zásady uchovávání dat, integrace s analytickými platformami a podpora různých typů hovorů (příchozí, odchozí, interní).

2. Výběr regionu

Určení oblasti, kde jsou nahrávky hovorů ukládány a zpracovávány, je zásadní pro dodržování předpisů a výkon:

Výběr globálního regionu: Ve výchozím nastavení si organizace mohou pro ukládání nahrávek hovorů zvolit jednu oblast, aby se zjednodušila správa a řízení.

Přepsání regionů na základě polohy: Pokud to vyžadují zákony o uchovávání dat nebo firemní zásady, může být nutné přepsat nastavení globálního regionu pro konkrétní lokality, aby se zajistilo, že nahrávky hovorů budou ukládány a zpracovávány v rámci požadovaných geografických hranic.

Požadavky na umístění dat: Návrh musí zohledňovat mezinárodní a místní předpisy na ochranu osobních údajů (jako je GDPR, CCPA nebo nařízení specifická pro danou zemi), které mohou určovat, kde a jak se nahrávky hovorů uchovávají.

Dalším kritickým aspektem, který je třeba řešit během plánování a návrhu řešení pro nahrávání hovorů, je odhad požadavků na úložiště. Přesné předpovídání potřeb úložiště je nezbytné pro zajištění dostatečné kapacity pro podporu probíhajících obchodních operací, dodržování předpisů a předcházení přerušení služeb.

Při určování očekávané poptávky po úložišti je třeba zvážit několik klíčových parametrů:

Objem nahraných hovorů: Zhodnoťte předpokládaný počet hovorů, které budou zaznamenány v daném časovém intervalu (např. za den, týden nebo měsíc). To zahrnuje nejen externí hovory, ale i interní komunikaci, pokud to vyžadují obchodní zásady nebo regulační nařízení.

Průměrná délka hovoru: Vypočítejte typickou délku nahraných hovorů, protože delší hovory spotřebují více úložného prostoru. Do odhadu by měly být zahrnuty také rozdíly v délce hovorů mezi různými odděleními nebo uživatelskými skupinami.

Doba uchovávání: Definujte dobu, po kterou musí být záznamy uchovávány, což je často dáno organizačními zásadami nebo externími předpisy (například standardy dodržování předpisů specifickými pro dané odvětví). Delší doby uchovávání zvýší celkové požadavky na skladování.

Projekce růstu: Zvažte očekávaný nárůst objemu hovorů nebo rozšíření rozsahu nahrávání, které může být důsledkem škálování podnikání, nových regulačních požadavků nebo zavádění dalších uživatelů či lokalit.

Důkladnou analýzou těchto parametrů mohou organizace vyvinout robustní strategii ukládání dat, která zajistí škálovatelnost, nákladovou efektivitu a shodu s předpisy pro jejich řešení nahrávání hovorů. Je také vhodné pravidelně kontrolovat a upravovat alokace úložiště s tím, jak se v průběhu času vyvíjejí vzorce používání.

Tísňové volání

Požadavek na směrování tísňového volání na příslušné dispečerské centrum je požadavkem pro každou volací službu, která nabízí službu PSTN. S je směrování tísňových volání nativní součástí řešení a zahrnuje podporu všech národních tísňových čísel v zemích, které podporují. Směrování tísňového volání je založeno na definovaném místě a metodě přístupu k PSTN daného místa. Tísňová čísla jsou předdefinovaná a specifická pro zemi, ve které jsou uživatelé a zařízení nasazeni.

Existují dva způsoby, jak uskutečnit tísňová volání. K dispozici je základní služba směrování tísňových volání a rozšířená služba směrování tísňových volání. Základní služba směrování tísňových volání použije administrátorem vybrané číslo k identifikaci polohy a trasy volání pro spojení se záchrannými službami. Pro základní tísňová volání je trasa hovoru obvykle přes zákaznickou PSTN volbu pro dané místo. Má také vylepšené směrování tísňových volání určené pro nasazení v USA a Kanadě, kde platí požadavky na shodu s předpisy, které vyžadují použití celostátního poskytovatele k doručení tísňových volání na správné dispečerské centrum.

Všichni zákazníci by měli nasadit alespoň základní konfiguraci pro tísňová volání. Základní tísňová volání vyžadují, aby alespoň jeden zákazník vlastnil +E.164 Každému místu definovanému v bude přiřazeno číslo. Pro základní tísňová volání bude každé místo definováno adresou, na kterou jsou v případě nouze vyslány policie, hasiči nebo záchranná služba. Ve většině případů je hlavní číslo pro danou lokalitu nejlepší volbou pro vyjádření fyzického místa nouzové situace. Přiřazení adresy k +E.164 Číslo je koordinováno s poskytovatelem PSTN. Obrázky níže ukazují přiřazení hlavního čísla, které se má použít jako číslo pro zpětné volání v tísňových situacích pro pobočku Richardson.

Konfigurace umístění ECBN

Ve většině případů postačuje jako expediční adresa pro dané místo adresa budovy. Pokud jsou však pro konkrétní uživatele nebo zařízení potřeba další podrobnosti o poloze, může administrátor použít stejný postup popsaný výše a přiřadit tato zařízení ke konkrétní adrese nebo přesnějšímu umístění v rámci adresy (například patro nebo místnost). V sekci Správa uživatelů v sekci Volání [] umožňuje karta [] Volání použít konkrétní číslo pro uživatele a jeho zařízení k získání konkrétní adresy pro odeslání. Následující obrázky ilustrují, jak lze zařízení přiřadit konkrétní číslo. Správce je zodpovědný za to, aby číslo používané zařízením mělo přiřazenu správnou odesílací adresu. Přiřazení adresy se obvykle provádí prostřednictvím poskytovatele PSTN dané lokality.

Konfigurace uživatelského ECBN

Pro nasazení telefonie v USA, která musí poskytovat vylepšená řešení pro tísňová volání, se pro směrování tísňových volání používá integrovaná technologie RedSky Horizon Mobility. Při používání služby RedSky pro směrování hovorů se musí administrátor zaregistrovat k účtu prostřednictvím společnosti Cisco a nakonfigurovat příslušné informace v sekci Volání -> Nastavení služby pro povolení této funkce. Jakmile je služba RedSky povolena na úrovni systému, administrátor povolí službu RedSky na úrovni každé lokality. Povolení funkce Vylepšené tísňové volání na daném místě aktivuje službu pro všechna zařízení přiřazená k danému místu. Zařízení, která podporují rozšířené tísňové volání, jsou telefony Cisco MPP, telefony Cisco PhoneOS a telefony Cisco.

Existují dvě nastavení pro povolení vylepšeného tísňového volání na daném místě. Volba Povolit RedSky přijímat informace o síťovém připojení a testovací volání by měla být použita k ověření správnosti konfigurace RedSky pro mapování zařízení a infrastruktury. Toto nastavení také umožňuje uskutečňovat testovací hovory na číslo 933 za účelem ověření polohy pomocí systému IVR od RedSky, který zjišťuje polohu volajícího. Ačkoli se tento dokument nebude zabývat konfigurací RedSky pro sledování polohy, měl by administrátor VŽDY otestovat vyhledávání polohy před aktivací nouzových volání pro směrování do RedSky. Jakmile je testování dokončeno a ověřeno jako přesné, administrátor přesměruje hovory na RedSky přepnutím směrování tísňových hovorů na RedSky. Tento přepínač přesměruje všechna tísňová volání pro danou lokalitu do RedSky, která je doručí do telefonního centra pro danou lokalitu.

Nastavení rozšířeného tísňového volání platí také pro klienty v místních i externích prostorách. V místním prostředí je lze sledovat stejným způsobem jako stolní telefony. Mimo prostory si uživatel bude moci dynamicky nastavit svou polohu přímo v souboru . Více informací o tísňových voláních naleznete v části Vylepšená tísňová volání pro

Licence

Existuje několik možností, jak uživatelům přiřadit licence.

Ruční přiřazení prostřednictvím

Administrátoři ručně přiřazují licence jednotlivým uživatelům prostřednictvím rozhraní.

Správci mohou upravovat licence služeb pro jednotlivé uživatele a přímo jim přiřazovat licence pro volání.

Šablony automatického přiřazení licencí

Pomocí šablon pro přiřazení licencí můžete automaticky přiřazovat licence uživatelům na základě nastavení skupiny nebo organizace.

Automatické licencování lze provést synchronizací adresářů nebo ruční aktualizací uživatelů, ale uživatelé musí mít platný +E.164 formátované telefonní číslo a telefonní čísla musí existovat na určitém místě před zřizováním uživatelů. Pokud nejsou splněny podmínky (např. neplatný formát telefonního čísla), licence nebudou přiděleny.

Hromadné přiřazení pomocí šablony CSV

Nahrajte soubor CSV s uživatelskými údaji a přiřazením licencí, abyste mohli přidat nebo upravit více uživatelů najednou.

Import CSV podporuje přidání až 20 000 uživatelů a přiřazení licencí, ale licence vyžadují specifická pole, jako je telefonní číslo a linka.

Přiřazení založené na API

Používejte API k programovému přiřazování licencí a správě uživatelů.

podporuje operace API pro správu uživatelů a licencí (People, SCIM 2.0 a Licenses API), které lze využít pro automatizaci přiřazování licencí. Rozhraní Licenses API umožňuje současné přiřazování licencí, telefonních čísel a poboček.
Tabulka 5. Možnosti zřizování uživatelů – shrnutí
Metoda přiřazení Výhody Nevýhody
Ruční přes Jednoduché pro několik málo uživatelů.
Umožňuje přesnou a podrobnou kontrolu nad přidělováním licencí.
Neškálovatelné, časově náročné
Náchylný k lidským chybám při ručním zadávání.

Automatické šablony licencí Škálovatelné
Snižuje počet manuálních chyb
Lze použít pro nové i stávající uživatele.
Vyžaduje platná telefonní čísla a umístění.
Složitější nastavení
Také vyžaduje skupiny uživatelů pro každou skupinu uživatelů s ekvivalentními licenčními požadavky.

Hromadné nahrání CSV Efektivní pro velké skupiny uživatelů
Umožňuje současné přiřazení licencí, telefonních čísel a poboček.
Vyžaduje pečlivé formátování CSV
Možnost chyb, pokud chybí telefonní čísla nebo klapky nebo jsou nesprávné.
Přiřazení založené na API Automatizovatelné, flexibilní.
Umožňuje současné přiřazení licencí, telefonních čísel a poboček.
Vyžaduje znalost vývoje a API.

Tabulka Možnosti zřizování uživatelů – shrnutí shrnuje možnosti zřizování uživatelů a jejich výhody a nevýhody. Tento přehled pomáhá vybrat nejlepší metodu přiřazení licencí na základě velikosti organizace zákazníka, možností automatizace a procesů a požadavků na zřizování uživatelů.

Kdykoli je to možné, společnost Cisco doporučuje přiřazovat licence k volání pomocí šablon licencí. To vyžaduje, aby pro každou skupinu uživatelů, která vyžaduje jedinečnou sadu licencí (příklad – Standard vs. Professional), existovala skupina s příslušným členstvím ve skupinách. Jak je popsáno v částech Uživatelské skupiny, uživatelské skupiny lze definovat ručně v podnikovém adresáři nebo synchronizovat z něj. Kombinace obou přístupů je možná.

Uživatelé patřící do více skupin získají licence ze všech přiřazení aplikovaných na všechny jejich skupiny. To umožňuje používat bezpečnostní skupiny specifické pro danou licenci v podnikovém adresáři ke správě přiřazení licencí, kde výsledné přiřazení uživatelských licencí je řízeno sjednocením členství ve skupinách.

Další informace naleznete v částech Nastavení automatického přiřazení licencí v Control Hub a Nastavení šablon automatického přiřazení licencí pro uživatele Webex Calling.

Požadavky na licenci

Tato část se zabývá pouze souvisejícími licencemi. Jiné typy licencí (příklad – registrace zařízení Webex, zasílání zpráv, schůzky) nejsou zahrnuty. V rámci procesu návrhu je třeba stanovit licenční požadavky. Je třeba vypočítat počet licencí pro následující typy licencí:

Standardní: počet jednotlivých uživatelů, kteří vyžadují standardní telefonní funkce.

Profesionální: počet uživatelů a pracovních prostorů vyžadujících pokročilé funkce telefonie. Virtuální linky a skupinová hlasová schránka mají nárok na 1:1 poměr pro každou profesionální licenci. Proto je ve vzácných případech, kdy počet požadovaných virtuálních linek nebo skupinových hlasových zpráv překročí počet uživatelů a pracovních prostorů vyžadujících pokročilé telefonní funkce, nutné počítat s dalšími profesionálními licencemi.

Pracovní prostor pro společnou zónu: počet sdílených prostor nebo míst ve společných prostorách vyžadujících standardní volání.

Zákaznická podpora: počet agentů a supervizorů, kteří vyžadují funkce zákaznické podpory. Zákaznická podpora zahrnuje profesionální licenci.

Seznam hovorů v trasách: počet požadovaných hovorů přes cloudově připojenou PSTN mezi místními uživateli and/or specializované lokální aplikace třetích stran.

Konzola spojovatelky: počet uživatelů, kteří potřebují přístup ke klientovi spojovatelské konzole.

Volací tarif Cisco (tarif odchozích hovorů): počet uživatelů, kteří potřebují číslo PSTN and/or přístup k odchozím voláním přes PSTN pro službu Cisco PSTN.

Pro profesionální pracovní prostory neexistuje žádný vyhrazený typ licence. Profesionální pracovní prostory spotřebovávají profesionální licenci.

Pracovní prostory určené pouze pro hot-desking nabízejí službu hostitele hot-deskingu a nouzová volání z hostitele hot-deskingu a nevyžadují žádnou licenci. Další informace naleznete v části Přidání a správa zařízení pouze pro aktivní pracovní plochu.

Chcete-li určit požadovaný typ licence pro každého uživatele a pracovní prostor na základě potřebných funkcí, podívejte se na Funkce dostupné podle typu licence pro Webex Calling.

Chcete-li rozlišovat mezi funkcemi nabízenými frontami hovorů v kombinaci s profesionální licencí a funkcemi zákaznické podpory, podívejte se na Porovnání funkcí fronty hovorů a zákaznické podpory Webex Calling.

Zřizování uživatelů

Při zřizování uživatelů ve Webexu je k dispozici několik možností, z nichž každá je vhodná pro různé potřeby a prostředí organizace:

Ruční zřizování: Administrátoři mohou přidávat a spravovat jednotlivé uživatele přímo v rámci . Tato metoda je přímočará, ale nejlépe se hodí pro malé organizace nebo omezený počet změn ze strany uživatelů.

Hromadné zřizování pomocí CSV: U větších uživatelských základen mohou administrátoři hromadně importovat a aktualizovat uživatele nahráním souborů CSV do formátu . To umožňuje efektivní správu až tisíců uživatelů najednou.

Možnosti synchronizace adresářů:
Konektor adresáře: Toto je nástroj pro automatickou synchronizaci používaný v prostředích služby Microsoft Active Directory. Synchronizuje uživatelské účty, skupiny a atributy podle plánu (každou hodinu, denně nebo týdně). Podporuje nastavení služby Active Directory pro více domén a více lesů a dokáže synchronizovat obrázky profilů a objekty místností.

Aplikace průvodce Entra ID (Azure AD): Tato metoda, určená pro organizace používající Microsoft Entra ID (Azure AD), poskytuje automatickou synchronizaci uživatelských účtů a atributů téměř v reálném čase přímo z Entra ID do . Je plně spravovatelný zevnitř a vyžaduje minimální nastavení.

Aplikace SCIM 2.0: Pro prostředí jiných poskytovatelů identit než od Microsoftu nebo jiné poskytovatele identit, jako je Okta nebo Duo, umožňují synchronizační aplikace založené na SCIM automatické zřizování a odstraňování zřizování uživatelů s mapováním atributů a synchronizací skupin.

Synchronizace uživatelů Unified CM: Tato možnost umožňuje vytvářet uživatelské účty na základě stávajících koncových uživatelů synchronizací z do. To vyžaduje, aby v místních clusterech běžela služba Cloud Connected UC (CCUC). Obecně se však doporučuje synchronizovat uživatele z centralizovaného cloudového adresáře, jako je Entra ID, spíše než přímo z .

Zřizování API: Veřejná API (People, SCIM 2.0) lze použít k zřizování uživatelů. Hlavní výhodou používání API je možnost integrace zřizování uživatelů s jinými podnikovými systémy.
Tabulka 6. Možnosti zřizování uživatelů pro
Metoda zřizování Popis Výhody Nevýhody
Ruční Create/manage uživatelé jednotlivě v Jednoduché pro několik uživatelů; nevyžaduje žádnou infrastrukturu Neškálovatelné; časově náročné pro mnoho uživatelů
Hromadné (soubor CSV) Import/update uživatelů hromadně pomocí CSV v Efektivní pro skupiny; není nutné žádné kódování Ruční příprava CSV; méně dynamické
Lidé a SCIM 2.0 API Programová správa uživatelů prostřednictvím rozhraní Webex API Flexibilní; podporuje automatizaci a integraci Vyžaduje rozvoj a infrastrukturu
Synchronizace adresáře Automatická synchronizace z AD, Entra ID, aplikací SCIM a Unified CM Automatizuje životní cyklus; podporuje filtrování a mapování Složitost nastavení: některé možnosti mají omezené funkce nebo vyžadují infrastrukturu
Tento přehled a tabulka odrážejí hlavní možnosti zřizování uživatelů, jejich výhody a omezení, aby vám pomohly vybrat nejlepší přístup pro potřeby vaší organizace.

Skupiny uživatelů

Správa uživatelských skupin umožňuje administrátorům organizovat uživatele do skupin pro efektivní hromadnou správu licencí, nastavení a zdrojů. Skupiny pomáhají zefektivnit správu tím, že používají zásady, licence a šablony nastavení pro více uživatelů současně, namísto individuální správy uživatelů.

Správa uživatelských skupin nabízí několik výhod, včetně:

Zjednodušená administrativa: Spravujte licence, nastavení a zásady pro více uživatelů najednou.

Konzistence: Používejte jednotná nastavení a licence napříč uživateli ve stejné skupině.

Škálovatelnost: Podporuje až 250 000 členů na skupinu.

Integrace: Synchronizujte skupiny z Microsoft Entra ID (Azure AD) nebo Active Directory pro automatizovanou správu uživatelů a skupin.

Flexibilita: Vytvářejte lokální skupiny nebo synchronizujte bezpečnostní skupiny; spravujte členství ve skupinách ručně nebo pomocí souborů CSV.

Alokace zdrojů: Řízení přístupu k integrovaným aplikacím a službám na základě členství ve skupině.

Hlavní případy použití uživatelských skupin při zřizování jsou:

Přiřazení licencí: Přiřaďte licence skupinám, aby se členům skupiny automaticky zpřístupňovaly služby, jako jsou volání, schůzky, zasílání zpráv nebo hybridní služby.

Šablony nastavení: Pro dosažení konzistentní uživatelské zkušenosti použijte na skupiny kolekce nastavení služeb (např. zasílání zpráv, schůzek, volání).

Hromadná správa uživatelů: Hromadné přidávání nebo odebírání uživatelů pomocí souborů CSV nebo synchronizace adresářů.

Automatizace a integrace: Pro automatizovanou správu životního cyklu uživatelů a skupin používejte API nebo synchronizaci adresářů.

Následující tabulka shrnuje různé možnosti správy uživatelských skupin a správy skupin v aplikaci .
Tabulka 7. Možnosti správy skupin a členství ve skupinách
Možnost Popis Výhody Nevýhody

skupinové zřizování (skupiny) Vytvářejte a spravujte skupiny přímo v aplikaci . Add/remove členy ručně nebo pomocí CSV. Plná kontrola nad členstvím ve skupině
Okamžité použití licencí a šablon
Snadné vytváření a úpravy skupin Vyžadovány manuální aktualizace
Riziko chyb při ručním nahrávání souborů CSV
Žádná automatická synchronizace s externími adresáři

Synchronizované skupiny z Entra ID (Azure AD) nebo Active Directory Automaticky synchronizovat bezpečnostní skupiny a členství z externích adresářových služeb. Automatická synchronizace snižuje manuální práci
Zajišťuje konzistenci s firemním adresářem
Podporuje velké organizace
Nelze upravovat členství ve skupině
Zpoždění synchronizace až 12 hodin
Vnořené skupiny vyžadují ruční výběr

Skupiny a SCIM 2.0 API (Skupiny) Pro programatickou správu skupin a členství používejte Skupiny nebo SCIM 2.0 API Automatizace a integrace s dalšími systémy
Škálovatelné pro rozsáhlá nebo složitá prostředí
Vyžaduje úsilí o vývoj
Složitost závisí na použití API

Synchronizované skupiny sice zajišťují konzistenci a nabízejí jednotné místo pro správu, ale je možný i hybridní přístup kombinující synchronizované skupiny a skupiny (spravované buď v řídicím centru, nebo prostřednictvím API). Takže například skupiny pro přiřazení licencí by mohly být synchronizované skupiny a samostatná sada skupin by mohla být použita pro přiřazení šablon uživatelů a volání.

Tento komplexní přístup ke správě uživatelských skupin umožňuje organizacím efektivně spravovat uživatelské licence, nastavení a zásady a zajišťuje tak konzistentní a škálovatelné prostředí pro spolupráci.

Doporučený postup při migraci z na

Primárním zdrojem dat pro uživatele je databáze, která obsahuje informace o koncových uživatelích. Obvykle však nepředstavuje autoritativní zdroj pro správu identity uživatelů a co je důležitější, na konci přechodného období bude ukončen, a proto je vyloučen jako dlouhodobý autoritativní zdroj informací o identitě.

Společnost Cisco doporučuje používat centralizovaný cloudový adresář, jako je Microsoft Entra ID (Azure AD), jako jediný zdroj pravdivých údajů o identitách uživatelů. Synchronizace uživatelů z Entra ID zajišťuje konzistenci, zjednodušuje správu a podporuje funkce jednotného přihlášení (SSO).

Aby se zajistilo, že všichni uživatelé jsou přítomni také v Entra ID, měly by organizace ověřit, zda uživatelské účty odpovídají účtům v Entra ID. Toho lze dosáhnout exportem seznamů uživatelů ze seznamů uživatelů Entra ID a jejich porovnáním se seznamy uživatelů.

Stručně řečeno, doporučenou metodou zřizování je synchronizace uživatelů z Microsoft Entra ID (Azure AD) do Webexu pomocí Průvodce Azure AD nebo aplikací SCIM. Ruční a hromadné zřizování v CSV jsou k dispozici jako doplňkové metody, ale jsou méně škálovatelné a pro velké organizace náchylnější k chybám. Zajištění toho, aby Entra ID bylo autoritativním zdrojem a aby všichni uživatelé existovali v Entra ID, je zásadní pro úspěšnou migraci a konzistentní uživatelskou zkušenost napříč různými prostředími.

Přechod z místní adresářové služby, jako je Active Directory, na cloudovou adresářovou službu, jako je Entra ID (Azure ID), je nezávislý na přechodu volání. Společnost Cisco doporučuje dokončit přechod na cloudovou adresářovou službu před zahájením přechodu volání.

Návrh uživatelských skupin

Po převedení podnikového adresáře z místního prostředí do cloudu shromážděte požadované skupiny uživatelů na základě požadavků na licencování a šablony funkcí. Pro každý skupinový dokument:

Název skupiny: unikátní název skupiny.

Licence: licence, které mají být přiřazeny této skupině (pokud existují) a rozsah (mají být licence přiřazeny stávajícím uživatelům nebo pouze novým uživatelům)

Šablony nastavení: Šablony volání pro aplikaci Webex a uživatele.

Synchronizace adresářů: Bude tato skupina synchronizována z podnikového adresáře, nebo se jedná o lokální skupinu Webex zřízenou v Control Hubu nebo prostřednictvím API?

Popis: Jak bude tato skupina používána a kteří uživatelé by měli být jejími členy

Tyto údaje budou později použity během implementační fáze k vytvoření lokálních skupin nebo skupin v podnikovém adresáři a ke správě členství uživatelů ve skupinách.

Jednotné přihlašování (SSO)

Společnost Cisco doporučuje pro ověřování uživatelů používat jednotné přihlašování (SSO). Používání SSO má několik přesvědčivých výhod, včetně:

Zjednodušené ověřování uživatelů: Uživatelé se mohou přihlásit jednou pomocí svých firemních přihlašovacích údajů (např. z Azure ID) pro přístup k dalším integrovaným aplikacím, čímž se eliminuje potřeba více hesel a snižuje se počet výzev k přihlášení. To zvyšuje zabezpečení tím, že zajišťuje, že firemní hesla nebudou po ověření nikdy uložena ani přenesena.

Zjednodušená správa uživatelů: Automatizuje vytváření, aktualizace a deaktivaci uživatelských účtů na základě změn v podnikovém adresáři, čímž snižuje administrativní režii a zajišťuje, že přístup mají pouze oprávnění uživatelé.

Vylepšené zabezpečení: Jednotné přihlašování (SSO) snižuje únavu hesel a riziko úniků hesel centralizací ověřování prostřednictvím důvěryhodných poskytovatelů identit (IdP).

Snadná integrace vícefaktorového ověřování (MFA): MFA lze snadno podporovat buď prostřednictvím řešení pro správu identit, jako je Cisco Duo, nebo prostřednictvím podpory MFA ze strany IdP.

Existuje několik možností, jak implementovat SSO pro služby:

Jednotné přihlašování (SSO) založené na SAML 2.0: Primární protokol podporovaný pro integraci SSO, který umožňuje bezpečnou výměnu ověřovacích informací mezi IdP a poskytovatelem služeb.

OpenID připojení (OIDC): Podporováno jako alternativní moderní ověřovací protokol pro integraci SSO.

Identita Webexu: Také podporováno jako možnost poskytovatele identity.

Jednotné přihlašování (SSO) je konfigurováno a spravováno centrálně prostřednictvím , což vyžaduje výměnu metadat mezi a vybraným poskytovatelem identity.

Po konfiguraci lze jednotné přihlašování (SSO) před aktivací otestovat, aby se zajistilo správné nastavení.

Společnost Cisco podporuje integraci s řadou testovaných a běžně používaných poskytovatelů identit (IdP) a systémů pro správu identit (IAM), včetně mimo jiné:

Cisco Duo

Okta

Služba Microsoft Active Directory Federation Services (ADFS)

Microsoft Azure

PingFederate

OpenAM

F5 BIG-IP.

Tito IdP splňují standardy SAML 2.0 nebo OpenID Connect a byli ověřeni z hlediska kompatibility s řešeními pro spolupráci Cisco.

Podpora více IdP

Umožňuje organizacím konfigurovat SSO s více IdP pro přizpůsobení složitým IT prostředím, jako jsou fúze, akvizice nebo decentralizovaná IT oddělení, kde různé skupiny používají různé IdP. Podporu více IdP lze implementovat buď pomocí funkce Multiple IdP v podnikovém systému IAM, jako je Cisco Duo, nebo prostřednictvím integrace s ním.

Podpora více poskytovatelů identity (IdP) řeší několik klíčových případů použití, kde organizace vyžadují flexibilní a bezpečné ověřování v různých IT prostředích:

1. Fúze a akvizice

Když se společnosti slučují nebo akvizují s jinými, často mají oddělené IT infrastruktury a samostatné poskytovatele identity (IdP), které se nemohou federovat. Podpora více IdP umožňuje uživatelům z obou organizací bezpečně se ověřovat a spolupracovat, aniž by bylo nutné okamžitě sjednocovat své systémy identity.

2. Několik nezávislých IT oddělení

Velké organizace nebo vládní instituce mohou mít více nezávislých IT oddělení, z nichž každé spravuje svého vlastního poskytovatele identity (IdP). Funkce více IdP umožňuje těmto oddělením spravovat si vlastní ověřovací systémy a zároveň uživatelům umožňovat bezproblémový přístup.

3. Různé uživatelské skupiny nebo domény

Organizace s různými uživatelskými skupinami (např. zaměstnanci vs. smluvní dodavatelé) nebo více e-mailovými doménami mohou nakonfigurovat pravidla směrování tak, aby směrovala požadavky na ověření na příslušného poskytovatele identity na základě členství v doméně nebo skupině. To podporuje diferencované zásady přístupu a bezpečnostní kontroly.

4. Podpora různých ověřovacích protokolů

podporuje IdP dle SAML a OpenID Connect (OIDC), což organizacím umožňuje integrovat různé typy poskytovatelů identity podle jejich stávajících požadavků na infrastrukturu a zabezpečení.

5. Vylepšené zabezpečení a dodržování předpisů

Povolením více IdP mohou organizace implementovat silnější mechanismy ověřování, včetně vícefaktorového ověřování (MFA) prostřednictvím integrací, jako je Duo, a vynucovat konzistentní bezpečnostní zásady napříč různými uživatelskými základnami.

6. Zjednodušený uživatelský zážitek

Uživatelé se mohou ověřovat pomocí svých stávajících přihlašovacích údajů od příslušných poskytovatelů identity (IdP), což poskytuje jednotný proces přihlašování i přes složitost více systémů identity.

I když podpora více IdP poskytuje flexibilitu, vyžaduje pečlivou koordinaci mezi bezpečnostními a identitními týmy, aby se zachovaly konzistentní bezpečnostní zásady a zabránilo se potenciálním zranitelnostem.

Duo MFA s jednotným přihlašováním pro

Duo Access Gateway (DAG) dokáže ověřovat uživatele pomocí stávajících místních nebo cloudových adresářů, jako je Active Directory (AD) a OpenLDAP. Podporuje také integraci s dalšími poskytovateli identit, jako jsou Microsoft ADFS, Microsoft Azure, Okta, OneLogin, CAS a Shibboleth. Tato flexibilita umožňuje organizacím využívat jejich stávající adresářovou infrastrukturu pro Webex SSO s Duo MFA.

Duo funguje jako silná ověřovací vrstva nad rámec ověřování primárního adresáře. Funguje jako poskytovatel identity (IdP) s využitím SAML 2.0 k vynucení dvoufaktorového ověřování (2FA) před udělením přístupu k . Duo vyhodnocuje kontext uživatele, zařízení a sítě na základě konfigurovatelných zásad, aby povolilo nebo zakázalo přístup, a tím zvýšilo zabezpečení nad rámec pouhého uživatelského jména a hesla. Duo také nabízí flexibilní ovládací prvky zásad, jako je například vyžadování vícefaktorové autentizace (MFA) při každém přihlášení u některých aplikací a méně často u jiných.

Mezi výhody Cisco Duo patří:

Rozšířené zabezpečení: Přidává vícefaktorovou autentizaci (MFA) odolnou proti phishingu pro ochranu přístupu a snížení rizika spojeného s kompromitací hesel.

Flexibilní zásady: Umožňuje podrobnou kontrolu nad požadavky na ověřování pro každou aplikaci nebo skupinu uživatelů.

Integrace se stávajícími adresáři: Podporuje lokální služby AD, OpenLDAP, cloudové adresáře a různé poskytovatele jednotného přihlašování (SSO), čímž minimalizuje změny infrastruktury.

Pohodlí pro uživatele: Podporuje jednotné přihlašování (SSO) pro snížení únavy z hesla tím, že uživatelům umožňuje jedno přihlášení a bezpečný přístup k více zdrojům.

Důvěryhodné koncové body: Podporuje důvěryhodnost zařízení pro klienty ve Windows a macOS, čímž zlepšuje zabezpečení.

Samoobslužná registrace: Inline registrace a výzva Duo zlepšují uživatelský zážitek během nastavení MFA.

Duo MFA s jednotným přihlašováním (SSO) využívá k ověřování uživatelů stávající adresáře, jako je Active Directory a OpenLDAP, nebo cloudové poskytovatele identit. Úlohou Duo je poskytovat silný, na zásadách řízený druhý faktor ověřování integrovaný prostřednictvím SAML 2.0, zvyšující zabezpečení a zároveň zachovávající pohodlí uživatelů prostřednictvím jednotného přihlašování (SSO). Mezi výhody patří vylepšené zabezpečení, flexibilní vynucování zásad, bezproblémová integrace a lepší uživatelský zážitek.

Společnost Cisco doporučuje implementovat pro uživatele jednotné přihlašování (SSO). Pro vylepšenou bezpečnostní integraci se doporučuje Cisco Duo.

Strategie Enterprise IAM a SSO by měla být nasazena před zahájením přechodu z prostředí .

Funkce

má kompletní sadu základních funkcí, které jsou součástí služby. To zahrnuje mnoho funkcí pro volání na podnikové úrovni, které jsou k dispozici již mnoho let. Mezi funkcemi a funkcemi nemusí být stoprocentní shoda, nicméně jak vidíte na obrázku níže, klíčové funkce volání jsou k dispozici v .

Funkce Webex Calling na podnikové úrovni

Kromě mnoha uživatelských funkcí má platforma i základní systémové funkce. Patří mezi ně funkce jako automatické telefonní operátory, fronty hovorů, parkování hovorů atd. Všechny dostupné základní funkce systému naleznete v sekci Služba → Volání → Funkce, jak je znázorněno na obrázku Základní funkce Webex Calling.

Základní funkce služby Webex Calling

Automatický operátor

Automatický operátor umožňuje 24/7 automatizace vyřizování příchozích hovorů, která umožňuje efektivní vyřizování hovorů bez nutnosti, aby někdo přijímal každý hovor.

Automatický operátor přijímá příchozí hovory a volajícímu nabízí nabídku možností, kam chce hovor přesměrovat. Může se jednat o osobu, hlasovou schránku nebo volací službu (např. frontu hovorů). Volající použije číselnou klávesnici svého telefonu k zadání čísla z nabídky automatického operátora.

Automatický operátor podporuje následující klíčové funkce:

Pracovní a mimopracovní rozvrhy

Plán svátků

Možnost vytáčení v nabídce, která nasměruje zákazníky tam, kam potřebují jít

Přizpůsobit pozdravy

Možnost vytočení podle jména

Možnosti přesměrování hovorů

Analytika a reporty Control Hubu.

Více informací naleznete v části Správa automatických telefonních operátorů.

Parkování hovorů

Parkování hovoru umožňuje uživatelům snadno přidržet hovor , aby ho mohl jiný uživatel snadno přijmout, až bude k dispozici. Také to umožňuje uživateli, který původní hovor přijal, uskutečňovat nebo přijímat další hovory, zatímco je hovor zaparkovaný.

K dispozici jsou dva typy parků pro volání :

Přímé parkování hovoru – umožňuje libovolnému uživateli zaparkovat hovor na pobočku jiného uživatele nebo na pobočku pro parkování hovoru, jak je definováno administrátorem

Skupina pro parkování hovorů – umožňuje definované skupině uživatelů automaticky parkovat hovory u dostupných parkovacích destinací definovaných pro danou skupinu. Těmito cíli mohou být linky členů skupiny nebo linky pro parkování hovorů.

V závislosti na konfiguraci a typu parkování mohou uživatelé přijímat hovory vytočením čísla *88+><extension of parked call>, stisknutím tlačítka linky přidruženého k pobočce pro parkování hovoru nebo použitím softwarové klávesy na svém IP telefonu.

K dispozici je možnost opětovného převzetí zaparkovaného hovoru po uplynutí stanovené doby uživateli, který hovor zaparkoval, nebo jinému uživateli.

Více informací naleznete v části Správa parkování hovorů v Control Hub.

Hromadné zvednutí hovorů

Vyzvednutí hovoru umožňuje administrátorovi definovat skupinu uživatelů (členů), kteří mohou přijmout hovor na telefon jiného člena. To dává uživateli možnost přijímat hovory, když jsou jeho spoluhráči zaneprázdněni a nemohou přijmout příchozí hovor.

Uživatelé ve skupině musí být na stejném místě.

Uživatelé mohou k přijmutí hovoru použít buď , nebo svůj stolní telefon.

:

Podporuje vizuální a zvuková oznámení

Upozornění na příchozí hovor

na bázi FAC (vytáčení *98) nebo oznámení o přijetí hovoru

Oznámení o vyzvednutí hovoru pro více linek.

Stolní telefony:

Upozornění na příchozí hovor

Zvukové signály a vizuální upozornění prostřednictvím LED displeje na ručním ovladači. Model 6821 podporuje pouze zvukové zvonkohry

Pokud vybraný typ oznámení není žádný

Oznámení o vyzvednutí hovoru pouze pro primární linky.

Další informace naleznete v části Konfigurace skupiny pro příjem hovorů.

Fronta hovorů

zahrnuje fronty pouze pro hlasové hovory jako součást svých základních funkcí a každý uživatel s profesionální licencí může být součástí fronty hovorů, agentem nebo supervizorem. Tato funkce umožňuje uživatelům efektivně komunikovat se zákazníky. Fronty hovorů podporují podmnožinu některých základních funkcí call centra, jako jsou hlasové fronty, zpětná volání, směrování podle dovedností nebo priorit, správa front agentů, analýzy, reporting atd.

Výzva společnosti Cisco k integraci Microsoft Teams umožňuje agentům přístup k hovorům a funkcím fronty hovorů přímo z jejich klienta Microsoft Teams.

Fronty volání podporují následující klíčové funkce:

Pozdravy a vzkazy (uvítání, útěcha, šepot atd.)

Pozastavit hudbu

Zpětné volání

Zásady směrování front (noční provoz, svátky, přesměrování)

Fronta agentů login/logout

Správa stavu fronty agentů

nebo podpora na pevném telefonu

Monitorování hovorů agenta supervizora, koučování, připojování nebo převzetí pomocí přístupových kódů k funkcím (FAC)

(přístup pro správce) pro:

správa front

Analýza a reporting agentů a front

Správa front, agentů a supervizorů.

Více informací naleznete v části Konfigurace fronty volání.

má doplňkovou funkci Customer Assist, která poskytuje další možnosti fronty hovorů a poskytuje agentům a supervizorům lepší uživatelský zážitek v rámci . Porovnání funkcí fronty hovorů a zákaznické podpory naleznete v článku Porovnání funkcí fronty hovorů a zákaznické podpory služby Webex Calling.

Skupina sdružených linek

Skupiny pro vyhledávání umožňují směrování příchozích hovorů na konkrétní skupinu uživatelů pomocí předem stanoveného vzoru směrování hovorů. Díky tomu je zajištěno, že hovory přijme správná skupina uživatelů nebo budou přesměrovány do hlasové schránky k následné komunikaci.

Jeden velký rozdíl mezi skupinami pro vyhledávání a frontami hovorů spočívá v tom, že hovory se ve skupinách pro vyhledávání nezařazují do fronty, takže pokud ve skupině pro vyhledávání nejsou žádní uživatelé k dispozici, aby hovor přijali, bude hovor odpojen, odeslán do hlasové schránky nebo přesměrován na jiné číslo (uživatele nebo službu).

Více informací naleznete v části Správa skupin hledání v Control Hub.

Provozní režimy

Funkce Provozní režimy umožňuje firmám efektivně směrovat hovory k různým cílům (uživatelé, hlasová schránka, volací služby, jako je fronta hovorů). Kam a kdy je hovor směrován, je založeno na denním a denním harmonogramu a kterýkoli uživatel může být oprávněn spravovat tyto režimy (harmonogramy) a řídit změny ve směrování hovorů.

Například hovory do fronty hovorů mohou být směrovány do jiné fronty hovorů s agenty v jiném časovém pásmu pro přijímání hovorů po pracovní době, během pracovní doby mohou být směrovány k místním agentům a během svátků mohou být směrovány do hlasové schránky pro následnou komunikaci po návratu agentů do kanceláře.

Oprávněný uživatel může přepínat mezi těmito různými scénáři (režimy) přesměrování hovorů, pokud potřebuje po určitou dobu změnit, kam jsou příchozí hovory směrovány. Tito uživatelé mohou spravovat režimy prostřednictvím svých 6800/7800/8800 Telefony MPP, telefony 9800 nebo v uživatelském centru na adrese Spravovat režimy.

Další informace naleznete v části Směrování hovorů na základě provozních režimů ve službě Webex Calling.

Skupina pagingu

Skupiny stránkování umožňují uživatelům uskutečnit jednosměrný hovor a odeslat zvukovou zprávu skupině uživatelů. Každá skupina může obsahovat až 75 cílových uživatelů. and/or pracovní prostory, které jsou dostupné vytočením předem definovaného čísla nebo linky.

Když uživatel volá do pagingové skupiny, je současně uskutečněn hovor se všemi přiřazenými cíli ve skupině, načež může volající nahlas vyslovit své zprávy a po jejich dokončení zavěsit.

Další informace naleznete v článku Konfigurace pagingové skupiny v Control Hub.

Nahrávky

podporuje nahrávání hovorů uskutečněných nebo přijatých uživatelem. To může být vyžadováno z důvodu zajištění kvality, zajištění bezpečnosti nebo školení. Ve výchozím nastavení se hovory nahrávají ve formátu , ale lze použít i jiné poskytovatele nahrávání třetích stran, pokud jsou vyžadovány další funkce nahrávání nebo splnění požadavků na dodržování předpisů a regulačních předpisů.

Při použití jako nahrávací platformy jsou všechny nahrané hovory spravovány v rámci . Plnoprávní administrátoři s rolí pracovníka pro dodržování předpisů mohou nahrávky přehrávat a stahovat. Bez role pracovníka pro dodržování předpisů může správce pouze mazat nahrávky.

Další informace o této funkci a seznam nahrávek třetích stran naleznete v části Správa nahrávání hovorů pro Webex Calling.

Dosažitelnost na jednom čísle

Dosah jednoho čísla umožňuje, aby hovory na telefonní číslo uživatele zvonily na více zařízeních. To může zahrnovat i jiné stolní telefony i mobilní telefony. Z těchto zařízení lze také uskutečňovat hovory a uživatelé si mezi nimi mohou hovory přesměrovávat a přenášet.

Další informace o této funkci a o tom, jak ji administrátor konfiguruje v aplikaci , naleznete v článku Konfigurace dosahu na jednom čísle (kancelář kdekoli).

Další informace o tom, jak si uživatelé mohou tuto funkci spravovat a konfigurovat v centru pro uživatele Webex (portál), naleznete v části Konfigurace dosahu na jednom čísle (kancelář kdekoli).

Skupina hlasové pošty

Skupiny hlasové schránky umožňují sdílenou hlasovou schránku, kterou lze přiřadit uživateli nebo funkci směrování hovorů. Mezi důvody, proč může být potřeba hlasová schránka, patří:

Univerzální hlasová schránka pro oddělení nebo pracovní skupinu

Přidání možnosti hlasové schránky do automatického telefonního operátora nebo vyhledávací skupiny

Odeslání přeplněných hovorů z fronty hovorů

Uživatelé, kteří potřebují pouze hlasovou schránku.

Další informace naleznete v článku Správa sdílené hlasové schránky a schránky příchozích faxů pro Webex Calling.

Aplikace Attendant Console je uvedena na stránce Funkce volání v aplikaci Webex, jedná se však o doplňkovou funkci, která vyžaduje zakoupení licence pro aplikaci Attendant Console.

Další informace naleznete v části Začínáme s Attendant Console.

Informace o všech funkcích, včetně některých doplňkových funkcí, naleznete v části Funkce dostupné podle typu licence pro Webex Calling.

Tabulka 1. Informace k zaznamenání pro každou lokalitu
Informace	Komentář
Rozsah(y) rozšíření	Každá lokalita může mít klapky začínající různými číslicemi. Jedna číslice musí být rezervována pro řídicí číslici pro vytáčení mezi stanicemi (například 8) a jedna pro řídicí číslici pro PSTN (například 9). Žádný rozsah rozšíření nemůže začínat žádnou z těchto dvou číslic. Všechny rozsahy rozšíření ve všech lokalitách musí mít stejnou délku.
Rozsah(y) DID	-
Řídicí číslice PSTN	-
Kód webu	Všechny kódy lokalit na všech místech musí být jedinečné a mít stejnou délku.
Hlavní číslo	Při vytváření umístění je třeba zřídit dva DID. Jedno jako hlavní číslo (například pro přiřazení automatické telefonní službě) a jedno pro portál hlasové schránky. Pro číslo hlasové schránky zřiďte jedno DID.
Číslo hlasové schránky
Počet licencí	Požadované licence podle typu, včetně Standard, Professional, Workspace, Route List, Outbound Calling Plan.
Souběžné hovory v rušné hodině	Součet souběžných hovorů mezi zařízeními a mezi zařízeními a lokální bránou (PSTN a hovory do zařízení). Je to nutné k určení požadované šířky pásma pro přístup k internetu.
Země	-
Časové pásmo	-
Jazyk	-
Kontakt (jméno, telefon, e-mail)	-
Adresa (ulice, město, stát, PSČ)	-
Fyzické umístění pro vyslání koncových bodů záchranných složek	Místo, kam lze zařízení odeslat pro tísňová volání, obvykle zahrnuje následující: adresa budovy, adresa budovy + číslo patra, adresa budovy + číslo apartmánu nebo adresa budovy + číslo patra + office/cubical číslo.
Unikátní fyzické umístění v síti pro každé zařízení pro tísňové služby	Fyzické umístění v síti pro tísňová volání obvykle zahrnuje následující: přepínač / switchport pro kabelová zařízení, bezdrátové přístupové body (AP) a identifikátory základní sady služeb (BSSID) pro bezdrátově připojená zařízení, and/or místní podsíť(e) IP pro koncová zařízení.

Tabulka 2. Příklad číslování podniku
Web	Rozsah rozšíření	Kód webu	Řada Enterprise
New York	2XXX	202	8 202 2XXX
SFO	3XXX	203	8 203 3XXX
RTP	2XXX	204	8 204 2XXX

Tabulka 3. Rozsahy prodloužení s pevnou délkou
Web	Rozsah rozšíření	Rozšíření	Kód webu	Řada Enterprise
New York	2XXX	2XXX	202	8 202 2XXX
SFO	8XXX	7XXX	203	8 203 7XXX
RTP	1XX	11XX	204	8 204 11XX

Tabulka 4. Přechod na sedmimístné vytáčení

Web	Rozšíření	Kód webu	Řada Enterprise	óda webu	Podnikový ange
New York	2XXX	22	8 22 2XXX	822	8 822 2XXX
SFO	8XXX	23	8 23 7XXX	823	8 823 7XXX
RTP	1XXX	24	8 24 11XX	824	8 824 11XX

Tabulka 5. Možnosti zřizování uživatelů – shrnutí
Metoda přiřazení	Výhody	Nevýhody
Ruční přes	Jednoduché pro několik málo uživatelů. Umožňuje přesnou a podrobnou kontrolu nad přidělováním licencí.	Neškálovatelné, časově náročné Náchylný k lidským chybám při ručním zadávání.
Automatické šablony licencí	Škálovatelné Snižuje počet manuálních chyb Lze použít pro nové i stávající uživatele.	Vyžaduje platná telefonní čísla a umístění. Složitější nastavení Také vyžaduje skupiny uživatelů pro každou skupinu uživatelů s ekvivalentními licenčními požadavky.
Hromadné nahrání CSV	Efektivní pro velké skupiny uživatelů Umožňuje současné přiřazení licencí, telefonních čísel a poboček.	Vyžaduje pečlivé formátování CSV Možnost chyb, pokud chybí telefonní čísla nebo klapky nebo jsou nesprávné.
Přiřazení založené na API	Automatizovatelné, flexibilní. Umožňuje současné přiřazení licencí, telefonních čísel a poboček.	Vyžaduje znalost vývoje a API.

Tabulka 6. Možnosti zřizování uživatelů pro
Metoda zřizování	Popis	Výhody	Nevýhody
Ruční	Create/manage uživatelé jednotlivě v	Jednoduché pro několik uživatelů; nevyžaduje žádnou infrastrukturu	Neškálovatelné; časově náročné pro mnoho uživatelů
Hromadné (soubor CSV)	Import/update uživatelů hromadně pomocí CSV v	Efektivní pro skupiny; není nutné žádné kódování	Ruční příprava CSV; méně dynamické
Lidé a SCIM 2.0 API	Programová správa uživatelů prostřednictvím rozhraní Webex API	Flexibilní; podporuje automatizaci a integraci	Vyžaduje rozvoj a infrastrukturu
Synchronizace adresáře	Automatická synchronizace z AD, Entra ID, aplikací SCIM a Unified CM	Automatizuje životní cyklus; podporuje filtrování a mapování	Složitost nastavení: některé možnosti mají omezené funkce nebo vyžadují infrastrukturu

Tabulka 7. Možnosti správy skupin a členství ve skupinách
Možnost	Popis	Výhody	Nevýhody
skupinové zřizování (skupiny)	Vytvářejte a spravujte skupiny přímo v aplikaci . Add/remove členy ručně nebo pomocí CSV.	Plná kontrola nad členstvím ve skupině Okamžité použití licencí a šablon Snadné vytváření a úpravy skupin	Vyžadovány manuální aktualizace Riziko chyb při ručním nahrávání souborů CSV Žádná automatická synchronizace s externími adresáři
Synchronizované skupiny z Entra ID (Azure AD) nebo Active Directory	Automaticky synchronizovat bezpečnostní skupiny a členství z externích adresářových služeb.	Automatická synchronizace snižuje manuální práci Zajišťuje konzistenci s firemním adresářem Podporuje velké organizace	Nelze upravovat členství ve skupině Zpoždění synchronizace až 12 hodin Vnořené skupiny vyžadují ruční výběr
Skupiny a SCIM 2.0 API (Skupiny)	Pro programatickou správu skupin a členství používejte Skupiny nebo SCIM 2.0 API	Automatizace a integrace s dalšími systémy Škálovatelné pro rozsáhlá nebo složitá prostředí	Vyžaduje úsilí o vývoj Složitost závisí na použití API

Implementovat

Připravenost k síti

Počáteční nastavení

Ověření domény

Nárokovat (převést) stávající uživatele

Konfigurace a testování synchronizace adresářů

Nastavení a otestování jednotného přihlašování (SSO)

Získávání, poskytování a ověřování licencí

Nastavení služby Webex Calling

Migrace pilotního projektu

Zajištění PSTN

Konfigurace umístění

Integrace s místním řízením hovorů

Migrace uživatelů v dávkách

Pracovní prostory

Zařízení pro poskytování

Konfigurace funkcí

Testování přijetí

Připravenost k síti

Prvním krokem při přechodu na [] je zajištění spolehlivého a bezpečného internetového připojení mezi místní sítí a cloudem.

Protože se většina organizací připojuje k internetu prostřednictvím jednoho nebo více firewallů nebo bezpečnostních zařízení, je nezbytné ověřit, zda jsou podporovány požadované toky provozu.

Správci sítě a zabezpečení musí těmto procesům rozumět z hlediska:

Směr (příchozí vs. odchozí)

Protokoly (Příklad - SIP TLS, SRTP, HTTPS)

Rozsahy IP adres používané službami

Čísla portů, která musí být otevřena nebo povolena.

Tím je zajištěno, že firemní firewally, zařízení NAT a další síťová infrastruktura jsou správně nakonfigurovány tak, aby zvládly provoz a zároveň byly zachovány podnikové bezpečnostní zásady.

Informace o požadovaných tocích, včetně IP adresy, portů a protokolů, naleznete v části Informace o referenčních portech pro volání Webex. Tyto informace použijte ke konfiguraci brány firewall, proxy serverů a další síťové infrastruktury v existujícím nasazení, abyste povolili síťové toky.

Decentralizované připojení k internetu z každé pobočky nebo pracoviště je doporučeným přístupem pro cloudové služby pro spolupráci, jako například . Tím, že tento model umožňuje lokální výstup provozu:

Snižuje zpoždění a jitter při oboustranném přenosu, čímž zlepšuje celkovou kvalitu hovoru

Efektivně se škáluje s tím, jak stále více uživatelů a webů přechází na

Bezproblémově spolupracuje s SD-WAN, která dokáže dynamicky směrovat relace k nejbližšímu vstupnímu bodu cloudu pro optimální výkon.

Umožňuje sledovat polohu uživatele na základě jeho veřejné IP adresy, což pomáhá s analýzou mediálních cest a řešením problémů.

Kromě toho musí organizace zajistit dostatečnou šířku pásma internetu na každém pracovišti. Šířka pásma by měla být dimenzována na základě očekávaného počtu souběžných hovorů, vybraného kodeku (např. Opus nebo G.711) a režijních nákladů na signalizaci, opakované přenosy a růst. To je v souladu s fází přípravy životního cyklu PPDIO a vytváří pevný základ pro migraci.

Počáteční nastavení

Podsekce počátečního nastavení v rámci implementační fáze nasazení je základem pro vytvoření dobře strukturovaného a spravovatelného prostředí cloudového volání. Tato fáze zahrnuje kritické úkoly, jako je nastavení organizace, získání a přidělení licencí a ověření a nárokování domén vaší společnosti, aby byla zajištěna řádná správa uživatelů a zabezpečení. Dále zahrnuje zřizování šablon licencí pro automatizaci přiřazování uživatelských licencí, konfiguraci jednotného přihlašování (SSO) pro zefektivnění ověřování uživatelů a zvýšení zabezpečení a úpravu nastavení služeb a klientů tak, aby odpovídalo organizačním zásadám a potřebám uživatelů. Dokončení těchto počátečních nastavení zajišťuje, že prostředí je správně nakonfigurováno pro škálovatelnost, zabezpečení a bezproblémové uživatelské prostředí, což připravuje půdu pro následné fáze nasazení a provozu.

Ověření domény

Aby bylo možné identifikovat uživatele registrované v e-mailových doménách vaší společnosti na , je nezbytné ověřit vaše domény. Bez ověření domény budou uživatelé přiřazeni k organizaci spotřebitelů, což vaší společnosti zkomplikuje správu uživatelů. Ověření domény je povinný krok, který vaší organizaci umožňuje efektivně si nárokovat a spravovat tyto uživatele.

Ujistěte se, že jsou ověřeny všechny domény spojené s e-mailovými adresami vašich uživatelů. Ověření domény není výhradní; stejnou doménu lze ověřit napříč více organizacemi.

Další informace o správě domén naleznete v části Správa domén.

Nárokovat (převést) stávající uživatele

Po úspěšném ověření domén můžete pokračovat v přihlašování uživatelů, kteří se zaregistrovali k používání e-mailových domén vaší společnosti, do vaší organizace. Tento proces konsoliduje všechny uživatele pod jednu organizační střechu, což umožňuje centralizovanou správu a efektivní administraci. Nárokováním těchto uživatelů zajistíte, že vaše společnost bude mít plnou kontrolu nad uživatelskými účty, což vám umožní efektivně přiřazovat příslušné licence, konfigurovat služby a poskytovat potřebnou podporu. Tento jednotný přístup ke správě zvyšuje zabezpečení, zjednodušuje zřizování uživatelů a zajišťuje konzistentní přístup ke službám v celé organizaci. Uplatňování nároků na uživatele také brání jejich správě v externích nebo spotřebitelských organizacích, čímž se zachovává integrita organizace a kontrola nad prostředky pro spolupráci.

Další informace o nárokování uživatelů naleznete v části Nárokování uživatelů na uživatele vaší organizace (převod).

Konfigurace a testování synchronizace adresářů

Pro bezproblémovou správu uživatelů a skupin můžete synchronizovat uživatele a skupiny z podnikového adresáře buď z Microsoft Entra ID (dříve Azure AD), nebo z Microsoft Active Directory (AD) do . Tento proces zajišťuje, že identity uživatelů a členství ve skupinách jsou v celém vašem prostředí konzistentně udržovány.

Pro organizace implementující postupné nasazení je klíčové kontrolovat a omezovat rozsah synchronizace během počátečního nasazení. To minimalizuje riziko nezamýšlených změn a umožňuje cílené testování před širším přijetím.

Nejefektivnější metodou pro filtrování synchronizovaných uživatelů je využití členství ve skupinách adresářů:

1
Vytvořte vyhrazenou synchronizační skupinu: V podnikovém adresáři (Microsoft Entra ID nebo AD) vytvořte bezpečnostní skupinu určenou speciálně pro synchronizaci (například skupina synchronizace).

2
Naplňte skupinu cílovými uživateli: Do této skupiny přidejte pouze uživatele, které chcete synchronizovat (například testovací skupinu během pilotní fáze). To vám umožňuje přesně kontrolovat, kdo je zahrnut do procesu synchronizace.

3
Nakonfigurujte synchronizační dohodu s filtrováním na základě skupin: Při nastavování synchronizační smlouvy v Directory Connectoru nebo zřizování Entra ID nakonfigurujte rozsah tak, aby zahrnoval pouze uživatele, kteří jsou členy určené skupiny.

Pro Microsoft Entra ID můžete v nastavení zřizování použít přiřazení na základě skupin.

Pro službu AD můžete definovat filtr LDAP, který zahrne pouze uživatele patřící do zadané skupiny.

4
V případě potřeby rozbalte skupinu: S postupem k širším fázím nasazení jednoduše přidávejte do synchronizační skupiny další uživatele nebo skupiny. Rozsah synchronizace se automaticky rozšíří o tyto uživatele, což umožní kontrolované a postupné zavádění.

Příklady kroků implementace:

V aktivním adresáři:

Vytvořte skupinu zabezpečení s názvem synchronizační skupina.

Přidejte požadované pilotní uživatele do této skupiny.

Nastavte Directory Connector s filtrem LDAP, například: (memberOf=CN=Webex Synchronizace Group,OU=Groups,DC=yourdomain,DC=com).

V Microsoftu zadejte ID:

Vytvořte skupinu s názvem synchronizační skupina

Přiřaďte skupinu k nastavení zřizování v Entra ID.

Pouze uživatelé v této skupině budou mít přístup k .

Synchronizaci založenou na skupinách vždy otestujte v neprodukčním prostředí, než ji použijete v celé organizaci.

Pravidelně kontrolujte členství ve skupinách, abyste zajistili, že jsou synchronizováni pouze autorizovaní uživatelé.

Pro průběžnou správu automatizujte aktualizace členství ve skupinách na základě obchodních pravidel nebo HR systémů, pokud je to možné.

Reference:

Synchronizace uživatelů Entra ID do Control Hubu

Nastavení aplikace Entra ID Wizard v Control Hubu

Konektor adresáře

Nastavení a otestování jednotného přihlašování (SSO)

Jednotné přihlašování (SSO) zvyšuje zabezpečení a zjednodušuje přístup uživatelů tím, že umožňuje uživatelům jednorázové ověření pomocí firemních přihlašovacích údajů a získání bezproblémového přístupu k službám. Podporuje integraci SSO s poskytovateli identity kompatibilními se standardem SAML 2.0, včetně Microsoft Entra ID (dříve Azure AD), federovaných řešení Active Directory (AD) a různých poskytovatelů identity třetích stran.

V tomto bodě by mělo být navržené nastavení SSO implementováno a otestováno.

Reference:

Integrace jednotného přihlašování v řídicím centru

konfigurace jednotného přihlášení pro správu webexu

Konfigurace jednotného přihlašování s Microsoft Entra ID

Jednotné přihlašování (SSO) s více IdP

Správa jednotného přihlašování (SSO) při integraci v Control Hubu

Získávání, poskytování a ověřování licencí

Součástí počátečního nastavení pro je nezbytné získat, zřídit a ověřit příslušné licence pro efektivní poskytování a správu služeb. Proces zadávání veřejných zakázek zahrnuje výběr typů licencí na základě uživatelských rolí a pracovních úloh, jako jsou licence Professional, Standard a Workspace. Licence jsou generovány a poskytovány prostřednictvím softwarových platforem společnosti Cisco nebo prostřednictvím partnerů. Po pořízení a zprovoznění je třeba ověřit správný počet licencí v souboru . Tento proces zajišťuje, že organizace má aktivované správné licence a připravené k použití při nasazení.

Jako součást počátečního nastavení licencování v aplikaci je důležité nakonfigurovat automatické licencování na úrovni organizace, aby se zefektivnilo přiřazování licencí novým uživatelům. Toto nastavení umožňuje automatické udělování licencí při přidání uživatelů do organizace, čímž se eliminuje nutnost ručního přiřazování licencí. Při konfiguraci automatického licencování na úrovni organizace vyberete služby, které chcete přiřadit, a definujete rozsah, například použití licencí pouze pro budoucí uživatele nebo zahrnutí i stávajících uživatelů.

Pokud však váš plán nasazení zahrnuje použití automatického licencování na úrovni skupiny, můžete se rozhodnout nepřiřazovat licence na úrovni organizace, abyste předešli konfliktům nebo duplicitnímu přiřazování licencí. U automatického licencování na úrovni skupiny jsou licence přiřazovány na základě členství ve skupině. Uživatelé ve více skupinách obdrží licence ze všech příslušných skupinových přiřazení.

Konfigurace přiřazení licencí na základě skupin musí být provedena po dokončení synchronizace adresářů, aby synchronizované skupiny existovaly a mohly být použity pro přiřazení licencí.

Konkrétně automatické přiřazení licence vyžaduje další podrobnosti o zřizování, jako je například umístění uživatele a přiřazení telefonního čísla. Pracovní telefonní číslo uživatele musí být v +E.164 formátu, předem zřízený a přiřazený k platnému umístění, aby se licence aktivovala automaticky. Pokud tyto podmínky nejsou splněny, uživateli nebudou služby zpřístupněny automaticky a může být nutný ruční zásah.

Stručně řečeno, pokud chcete široké přiřazení licencí pro celou organizaci, nakonfigurujte automatické licencování na úrovni organizace pro nové uživatele. Pokud dáváte přednost podrobnější kontrole nebo máte různé licenční potřeby pro každou skupinu, nakonfigurujte automatické licencování na úrovni skupiny a vyhněte se přiřazování licencí na úrovni organizace, abyste zabránili překrývání a zajistili správnou správu licencí.

Nastavení služby Webex Calling

Je nezbytné provést komplexní kontrolu a konfiguraci nastavení globálních služeb v rámci .

Začněte tím, že otevřete a přejdete do sekce nastavení. Pečlivě prozkoumejte každou konfigurovatelnou možnost, včetně, ale nikoli výhradně, konfigurace interního vytáčení, parametrů nouzových volání, zásad směrování hovorů, správy hlasové schránky a výchozího nastavení zařízení.

Upravte tato globální nastavení tak, aby odrážela zásady a rozhodnutí o návrhu vaší organizace.

Také nastavení nastavení a šablony uživatelů a aplikací.

Migrace pilotního projektu

Během implementační fáze představuje provedení pilotní migrace kritický milník v ověření přechodu z na . Tento pilotní projekt zahrnuje zprovoznění reprezentativní podmnožiny uživatelů na jedné nebo více lokalitách na platformě, čímž se zajistí, že vybraná populace odráží rozmanité případy užití a organizační role. Souběžně s migrací uživatelů je nutné převést na ekvivalentní systémy nezbytné služby pro spolupráci, včetně hlasové schránky, automatických telefonních operátorů, front hovorů a skupin pro vyhledávání, aby byla zachována kontinuita provozu a funkčnost služeb.

Pilotní migrace by měla využívat stejnou kombinaci nástrojů poskytovaných společností Cisco a migračních utilit třetích stran, které jsou plánovány pro širší nasazení v organizaci, a zajistit tak důkladné ověření procesů, automatizovaných pracovních postupů a integračních bodů za reprezentativních podmínek.

Hlavní cíle tohoto pilotního nasazení jsou dva: zaprvé, ověřit a zdokonalit komplexní procesy přechodu, včetně pracovních postupů pro zřizování uživatelů, postupů migrace dat a konfigurací koncových bodů; a zadruhé, komplexně ověřit funkčnost migrovaných služeb v reálných provozních podmínkách.

Tento fázovaný přístup umožňuje projektovému týmu identifikovat a napravit jakékoli technické nebo procedurální problémy v kontrolovaném prostředí, shromáždit zpětnou vazbu od uživatelů k novému prostředí platformy, posoudit efektivitu vybraných migračních nástrojů a získat důvěru v metodologii migrace předtím, než přistoupí k širšímu nasazení v organizaci.

Poznatky získané během této pilotní fáze jsou klíčové pro optimalizaci následných migračních vln a zajištění plynulého přechodu s minimalizací rizik pro celý podnik.

Zajištění PSTN

Chcete-li si pořídit služby PSTN pro , nejprve vyberte možnost připojení PSTN v .

Pokud organizace plánuje zachovat hybridní duální řízení hovorů ( fáze 1 na obrázku Fázovaný přechod volání): Hybridní a cloudové), ať už dočasně nebo na dobu neurčitou, budou muset nasadit jednu nebo více lokálních bran pro místní PSTN, aby umožnily volání mezi koncovými body.

Pokud je konečným cílem úplný přechod ( fáze 2) do cloudu včetně PSTN, pak bude pro PSTN vyžadován buď Cisco Calling Plan, nebo možnost Cloud Connect.

Před konfigurací telefonních čísel v systému . si je objednejte a přeneste u vybraného poskytovatele. Objednávání telefonních čísel nebo iniciování objednávek přenesení je možné pouze required/possible pro místní PSTN a Cloud Connect pro . U volacích tarifů Cisco se objednávání a přenesení inicializuje z Control Hub ihned po vytvoření lokality a v zemích, kde je volací tarif Cisco k dispozici. Další informace o tarifech Cisco Calling naleznete v části Začínáme s tarify Cisco.

V rámci implementace PSTN se ujistěte, že váš poskytovatel povolil pro vaši lokalitu příchozí i odchozí služby PSTN. Dále proveďte zkušební hovory, abyste ověřili, zda jsou hovory správně směrovány přes vámi zvolené připojení PSTN.

Konfigurace umístění

Před přidáním uživatelů a zařízení do služby je nutné zřídit volající lokality. Pro každé místo je nutné zadat platnou adresu. V USA a Kanadě je tato adresa ověřena a platforma ji používá k odesílání informací o poloze PIDF-LO pro tísňová volání.

Při konfiguraci umístění, která používají místní PSTN, je nutné odpovídajícím způsobem nastavit lokální brány. V aplikaci musí být pro každou lokální bránu vytvořena kmenová linka a skupina směrování a tato skupina směrování je poté přiřazena jako volba PSTN pro dané umístění. Společnost Cisco důrazně doporučuje vždy vybrat skupinu tras jako volbu PSTN, protože tento přístup umožňuje v budoucnu snadno přidat další trunkové linky a podporuje škálovatelnost i redundanci. Společnost Cisco také doporučuje povolit podporu duální identity a P-Charge-Info na každém PSTN trunku, protože to zjednodušuje identifikaci fakturované strany pro odchozí přímé nebo přesměrované hovory. Pokud váš poskytovatel PSTN používá pro fakturaci jinou hlavičku, můžete zkopírovat informace ze hlavičky P-Charge-Info na lokální bráně do požadované fakturační hlavičky.

Pro lokality, které používají jako PSTN službu Cloud Connect nebo Cisco Calling Plan, jednoduše během nastavení vyberte příslušnou možnost PSTN pro danou lokalitu. Pokud dané místo používá buď Cloud Connect pro PSTN, nebo místní PSTN, budete muset přidat telefonní čísla, která byla objednána v předchozím kroku. Čísla lze přidat jako neaktivní, pokud je nechcete ihned zahrnout do směrování hovorů; aktivovat je můžete později, až budou přiřazena uživatelům nebo funkcím.

Je důležité vždy nastavit hlavní číslo pro každou lokalitu. Hlavní číslo lze přiřadit buď uživateli, nebo funkci, například automatickému telefonnímu operátorovi. Chcete-li na daném místě povolit hlasovou schránku, nezapomeňte nastavit pilotní číslo hlasové schránky, známé také jako číslo hlasového portálu.

Mezi další nastavení pro volání na daná místa patří konfigurace podrobností o tísňovém volání, jako je číslo pro zpětné volání v tísňovém volání, možnosti oznámení a rozšířené funkce tísňového volání. Také byste měli zkontrolovat a upravit nastavení nahrávání, jazykové předvolby a konfigurace zařízení podle potřeby pro každé místo. Pokud vaše organizace používá zkrácené vytáčení mezi pracovišti v síti s čísly platnými pro danou společnost, nezapomeňte v nastavení interního vytáčení nakonfigurovat pro dané místo jedinečný kód pracoviště. A konečně, pokud externí vytáčení vyžaduje číslici pro odchozí vytáčení, nezapomeňte ji nastavit v nastavení externího vytáčení. Pokud je nakonfigurována číslice pro odchozí vytáčení, společnost Cisco doporučuje povolit vynucení číslice pro odchozí vytáčení, aby byla zajištěna konzistence.

Integrace s místním řízením hovorů

Pro integraci s místním řízením hovorů je nutné nakonfigurovat linky, skupiny směrování, podnikové vytáčené plány a nastavení umístění i globální nastavení. Začněte nastavením tranků a lokálních bran určených pro propojení s místním systémem řízení hovorů; tento krok je vyžadován pouze v případě, že jsou vyhrazené trunky nezbytné. Pokud jsou pro vaše nasazení dostatečné stávající kmenové linky a skupiny tras, lze je znovu použít pro místní propojení bez další konfigurace.

Jakmile jsou nastaveny kmenové linky a skupiny směrování, pokračujte k vytvoření podnikových plánů vytáčení a přiřaďte příslušnou skupinu směrování jako cíl pro každý plán vytáčení. Pokud integrace zahrnuje více místních systémů řízení hovorů připojených prostřednictvím různých kmenových linek, bude vyžadováno více telefonních plánů. Je důležité zajistit, aby tyto plány vytáčení obsahovaly pouze vzory nezbytné pro směrování hovorů do místních cílů.

Pokud vaše nasazení vyžaduje podporu pro směrování neznámých poboček, měla by být tato funkce povolena na úrovni umístění. Pokud je navíc aktivováno směrování neznámé pobočky, musíte v části Směrování hovorů mezi objekty v nastavení volacích služeb v . To zajišťuje bezproblémové směrování hovorů a správné zpracování scénářů vytáčení na základě poboček ve vašem integrovaném prostředí.

Migrace uživatelů v dávkách

Při migraci uživatelů z do se může stát, že nebudete moci přesunout všechny uživatele najednou. To může být způsobeno několika důvody, mimo jiné počtem webů nebo uživatelů a dobou trvání přechodu webu. and/or skupina uživatelů najednou, omezené IT nebo pracoviště, které by měly podporovat změnové okno, délka trvání změnového okna, složitost změny atd.

Při migraci uživatelů ve fázích je zásadní identifikovat, kteří uživatelé potřebují migrovat společně ve stejné dávce. Primárním cílem je migrovat uživatele, kteří jsou navzájem závislí na svých službách a funkcích volání. Chcete zajistit, aby všechny jejich funkce volání (příklad – fronty hovorů) byly plně funkční tak, jak byly před přechodem na .

I když implementujete propojení volání mezi lokálními branami a s nimi, nemůžete v rámci tohoto připojení rozdělit sdílené služby nebo funkce. Proto je třeba identifikovat závislosti mezi uživateli pomocí funkcí, jako jsou:

Monitorování ostatních uživatelů pomocí BLF

Ve stejném pilotním projektu, frontě hovorů atd.

Sdílené řádky

Používání vyzvednutí hovoru

Používání stejných čísel pro parkování hovorů

Interkom

Executive/Admin.

Příkladem by mohl být uživatel, který je součástí skupiny Hunt Group, která je převáděna na . Tento uživatel přejde do skupiny Hunt Group a ke všem ostatním členům skupiny Hunt Group. Proto mohou Hunt Group a její členové po přechodu úspěšně přijímat hovory na nové platformě.

To se stává náročnějším, když jsou uživatelé připojeni k různým skupinám uživatelů pro různé volací služby a funkce. To bude vyžadovat současný přechod více než jedné skupiny uživatelů a jedné volací služby.

Použijte výstup z nástroje Migration Insights nebo nástroje třetí strany, který jste použili ve fázi přípravy, k určení, kteří uživatelé a funkce by měli být seskupeni. Tento výstup by měl být použit k vytvoření vašeho migračního plánu a poskytne vám informace o tom, jak seskupíte uživatele a funkce, které je třeba převést společně.

Klíčové kroky při přechodu skupiny uživatelů jsou:

Identifikace uživatelů pro společnou migraci

Ověřte, zda jsou všichni uživatelé přihlášeni

Ověřte, zda všechny TN pro uživatele existují v

Ověřte správný formát telefonního čísla v adresáři

Ujistěte se, že jsou šablony licencování a nastavení pro uživatelské skupiny správně nastaveny.

Ověření nebo konfigurace všech volacích služeb a funkcí pro skupinu uživatelů (před přechodem nebo během něj, dle potřeby)

V podnikovém adresáři přidat uživatele do skupiny uživatelů s povoleným voláním

Využijte nástroje – nástroje pro migraci uživatelů a funkcí and/or nástroje třetích stran

Disable/Delete user/device telefonní číslo a volání features/services po přechodu.

Po migraci skupiny uživatelů otestujte podmnožinu uživatelů, abyste ověřili, zda všechny jejich funkce a služby volání fungují správně. Pokud jsou funkce volání, jako je fronta hovorů, skupiny pro vyhledávání atd., převedeny se skupinou uživatelů, otestujte tyto služby volání, zda správně fungují.

Pracovní prostory

V se pracovní prostor vztahuje ke sdílenému místu (například konferenční místnosti, prostor pro setkání nebo aktivnímu stolu), kterému lze přiřadit zařízení, linky a uživatele. Na rozdíl od tradičních telefonů Unifed CM jsou pracovní prostory:

Zaměřeno na lokalitu: vázané na fyzické prostory.

Flexibilní pro zařízení: může mít jedno nebo více zařízení (stolní telefony, tabule atd.).

Jakmile jsou pracovní prostory identifikovány jako součást přechodu na , lze je přidat v sekci Zařízení. Každý pracovní prostor potřebuje přiřazení zařízení a pokud se již nachází v Unified CM, je třeba jej resetovat nebo znovu zřídit. Funkce, jako je hlasová schránka, přesměrování hovorů a přijímání hovorů, lze povolit nebo zakázat a podle potřeby lze použít zásady pro videohovory, parkování hovorů a mobilitu. Otestujte každý pracovní prostor uskutečňováním interních a externích hovorů, testováním videohovorů, konferencí a funkcí pro mobilitu. Nakonec informujte uživatele o všech příslušných postupech pro zařízení a rezervace pracovních prostor.

Další informace o pracovních prostorech v naleznete v části Pracovní prostory.

Zajišťovací zařízení

Telefony, které jsou aktuálně registrovány u, bude nutné v rámci přechodu do cloudu migrovat do cloudu. Aby byla migrace co nejjednodušší a minimalizovala riziko selhání, společnost Cisco doporučuje migrovat fyzická pracoviště nebo oddělení současně. Kvůli závislostem funkcí však může být nutné migrovat uživatele dávkově. Více informací naleznete v části Dávková migrace uživatelů.

Všechny podporované telefony, ze kterých potřebujete přejít, bude nutné nakonfigurovat jako uživatelské nebo pracovní a fyzický telefon bude nutné znovu nakonfigurovat pro registraci u služby . Kromě toho je u telefonů řady 7800 a 8800 nutné aktualizovat firmware z verze Enterprise na firmware pro víceplatformní telefony (MPP). Tento proces zahrnuje načtení přechodného firmwaru před načtením firmwaru MPP potřebného pro registraci. Vyžaduje také příslušnou migrační licenci. Společnost Cisco tento proces v posledních několika letech vylepšila, aby vám usnadnila upgrade firmwaru vašich podnikových telefonů na firmware MPP. Další informace o postupu aktualizace firmwaru naleznete v článku Převod IP telefonů Cisco řady 7800 a 8800 mezi firmwarem Enterprise a MPP.

Kromě kroků popsaných v tomto článku má vestavěný nástroj Migrace telefonu do služby Webex Calling, který můžete použít k migraci telefonů 7800 a 8800 z firmwaru Enterprise na MPP. Tento nástroj vám také umožňuje přidávat telefony a přiřazovat je příslušným uživatelům nebo pracovním prostorům. Další informace o používání nástroje naleznete v části Migrace telefonu.

Pro telefony řady 9800 registrované s výše uvedeným požadavkem na migraci firmwaru se nevztahuje. Tyto telefony používají systém PhoneOS, který je podporován jak operačními systémy . Chcete-li tyto telefony převést, budete je muset přidat do služby Webex Calling, přiřadit je uživateli nebo pracovnímu prostoru a poté telefony obnovit do továrního nastavení. Spouštěcí sekvence PhoneOS pro registraci obrázek níže ukazuje spouštěcí sekvenci PhoneOS a jak se telefon zaregistruje po přidání do , i když je telefon stále zřízen na and/or Používají se možnosti DHCP (příklad - 150).

Spouštěcí sekvence PhoneOS pro registraci

Podporuje obnovení továrního nastavení zařízení PhoneOS, což umožňuje bezdotykové připojení k . Administrátoři mohou vzdáleně obnovit tovární nastavení telefonů 9800 a 8875 prostřednictvím stránek pro správu CUCM, což eliminuje potřebu fyzického přístupu k telefonům pro jejich připojení k . Tato funkce je podporována u balíčků Device Pack od 9. září 2025:

CUCM v15 - Unified Communications Manager verze 15

CUCM v14 - Unified Communications Manager verze 14.

Více informací o procesu registrace pro řadu 9800 naleznete v části Proces registrace.

Kromě IP telefonů Cisco může být vyžadováno zprovoznění dalších zařízení, jako jsou analogové telefonní adaptéry (ATA), bezdrátové telefony (Wi-Fi, DECT), videozařízení, hlasové brány a zařízení a telefony^třetích stran . Mnoho z těchto zařízení nemá, jako je tomu u IP telefonů, možnost aktualizace firmwaru, která by jim umožnila přejít z podnikového firmwaru na cloudový firmware. Proto každé z těchto zařízení zřídíte v Control Hub. Na některé z nich nelze přejít a bude je nutné nahradit ekvivalentním modelem (např. ATA 191/192) a další budou vyžadovat ruční rekonfiguraci and/or změny softwaru.

Hlasové brány – Chcete-li migrovat svou lokální bránu, viz Migrace lokální brány.
Další informace o konfiguraci hlasové brány VG400, VG410 nebo VG420 v Control Hub naleznete v části Lokální brána

Analogový telefonní adaptér (ATA) – Chcete-li začít s adaptéry Cisco ATA 191 a 192, podívejte se na Cisco ATA.

Bezdrátový telefon Wifi - Chcete-li integrovat bezdrátové telefony 840 a 860, viz Integrace bezdrátového telefonu Webex.

Bezdrátové telefony DECT – Chcete-li začít s novou řadou Cisco IP DECT 6800, podívejte se na Cisco IP DECT.

Chcete-li v Control Hubu vytvořit a spravovat digitální síť DECT, viz Správa sítě DECT

Další informace o zařízení Cisco IP DECT 6800 naleznete v Průvodci nasazením

zařízení a telefony třetích^stran - Spolupracujte s dodavateli třetích^stran stran na device/phone požadavky a proces jejich migrace nebo nahrazení za účelem podpory.

Konfigurace funkcí

Veškeré funkce volání, které jsou vyžadovány, je třeba zřídit před přechodem nebo během něj. Jak bylo popsáno v části Dávková migrace uživatelů, je nutné funkce volání nakonfigurovat a převést při přechodu uživatelů, kteří je používají.

Podrobnosti o konfiguraci jednotlivých funkcí naleznete v příslušných článcích nápovědy k konfiguraci.

Automatické telefonní operátory – Chcete-li spravovat automatické telefonní operátory, viz Automatické telefonní operátory

Parkování hovorů – Chcete-li spravovat parkování hovorů, viz Parkování hovorů

Převzetí hovoru – Chcete-li nakonfigurovat skupinu pro převzetí hovoru, viz Převzetí hovoru

Fronty hovorů – Chcete-li konfigurovat frontu hovorů, viz Fronta hovorů

Skupiny lovců – Chcete-li spravovat skupiny lovců, viz Správa skupiny lovců

Provozní režimy – Informace o směrování hovorů na základě provozních režimů naleznete v části Směrování hovorů na základě provozních režimů

Skupiny stránkování – Chcete-li konfigurovat skupinu stránkování, viz Konfigurace skupiny stránkování

Nahrávky – Chcete-li spravovat nahrávání hovorů pro , viz Správa nahrávek

Dosah na jedno číslo – Chcete-li nakonfigurovat dosah na jedno číslo (kancelář kdekoli), viz Konfigurace dosahu na jedno číslo

Skupina hlasové schránky – Chcete-li spravovat sdílenou hlasovou schránku a schránku příchozích faxů pro , viz Správa hlasové schránky.

Testování přijetí

Akceptační testování zajišťuje, že migrované prostředí splňuje funkční požadavky, funguje podle očekávání a poskytuje bezproblémový uživatelský zážitek napříč všemi komunikačními pracovními postupy. Tento ověřovací proces je mnohostranný a zahrnuje vše od zřizování uživatelů a přiřazování čísel až po provozní výkon pokročilých funkcí volání.

Tato část uvádí příklady a zdůrazňuje klíčové aspekty, které je třeba zvážit během akceptačního testování; není však zamýšlena jako vyčerpávající nebo komplexní kontrolní seznam.

Zřizování uživatelů a přidělování čísel

Základním aspektem akceptačního testování je ověření, zda jsou všichni uživatelé v rámci . To vyžaduje důkladné porovnání mezi zdrojovým adresářem () a nově vytvořenou uživatelskou základnou, aby se zajistilo, že každý uživatelský účet spolu s přidruženými atributy, jako jsou čísla poboček a přiřazení přímé volby (DID), byl správně migrován. Úplnost zřizování je zásadní nejen pro provozuschopnost od prvního dne, ale také pro průběžnou správu a podporu.

Ověření přiřazení čísla zahrnuje potvrzení, že každému uživateli je přiřazena správná linka a externí číslo a že tato čísla správně směrují interní (v síti) i externí (PSTN) volání. Je nezbytné zkontrolovat případná překrývání, chybějící přiřazení nebo nesprávné konfigurace, které by mohly vést k chybám směrování hovorů nebo přerušení služby.

Toky volání PSTN a prezentace ID volajícího

Robustní postup akceptačního testování musí zahrnovat kompletní ověření toků volání PSTN. To zahrnuje scénáře příchozích i odchozích hovorů. U příchozích hovorů přes PSTN by měl testovací tým potvrdit, že jsou hovory doručovány do zamýšlených koncových bodů, ať už se jedná o jednotlivé uživatele, fronty hovorů, skupiny pro vyhledávání nebo automatické telefonní operátory. Odchozí hovory přes PSTN musí být úspěšně uskutečněny, se zvláštním zřetelem na správné doručení a zobrazení informací o identifikaci volajícího. To zahrnuje zajištění toho, aby se externím příjemcům zobrazovalo správné jméno a číslo volajícího v souladu s organizačními zásadami a regulačními požadavky.

Testování by se mělo zabývat i scénáři failoveru, jako je například zpracování nedostupných koncových bodů nebo výpadků sítě. To pomáhá potvrdit, že záložní mechanismy a alternativní směrování fungují správně a zachovávají kontinuitu a spolehlivost služeb.

Toky volání v síti

Interní neboli síťové toky hovorů tvoří páteř podnikové komunikace. Akceptační testování v této oblasti ověřuje, zda jsou hovory mezi uživateli v rámci organizace správně směrovány a zda funkce, jako je přesměrování hovorů, přidržení, přesměrování a konference, fungují podle očekávání. Musí být potvrzena integrita plánů vytáčení, propojení mezi pobočkami a podpora organizačních zásad volání.

Zpracování uživatelských hovorů a ověření funkcí

Důležitým aspektem akceptačního testování je ověření, jak uživatelé zpracovávají hovory pomocí a podporovaných stolních telefonů. Tento proces se zaměřuje na ověření, zda jsou každodenní pracovní postupy volání intuitivní a spolehlivé a zda mají uživatelé bezproblémový přístup k základním funkcím nezbytným pro jejich role. Testování by mělo posoudit, s jakou snadností mohou uživatelé uskutečňovat a přijímat hovory, spravovat funkce přidržení a obnovení hovoru a provádět slepá i konzultativní přepojení. Je také nezbytné ověřit, zda jsou snadno dostupné a bezproblémově fungují přesměrování hovorů, konference a další pokročilé funkce, jako je parkování a vyzvedávání hovorů nebo aktivace režimu Nerušit.

Měla by být vyhodnocena srozumitelnost a rychlost reakce s ohledem na to, jak uživatelé interagují s historií hovorů, hlasovou schránkou a integrovanými adresáři. Zvláštní pozornost by měla být věnována možnosti přesouvat aktivní hovory mezi zařízeními a efektivnímu používání ovládacích prvků během hovoru v aplikaci nebo na fyzických telefonech. Konečným cílem je zajistit, aby zkušenost koncových uživatelů byla konzistentní, efektivní a plně podporovala komunikační potřeby organizace po migraci.

Fronty hovorů: Zkušenosti s agenty a supervizory

Fronty volání se často používají pro zpracování scénářů s vysokým objemem příchozích hovorů. Akceptační testování se zde zaměřuje na několik aspektů. Nejprve je třeba ověřit, zda jsou hovory distribuovány agentům podle nakonfigurované logiky fronty, jako je například round robin, nejdelší nečinnost nebo současné vyzvánění. Zobrazení hovorů ve frontě na plochách agentů musí být prověřeno z hlediska srozumitelnosti a snadnosti použití, aby bylo zajištěno, že agenti mohou hovory efektivně přijímat, přidržovat a přesměrovávat.

Pro supervizory by mělo být prostředí počítače vyhodnoceno z hlediska funkcí, jako je monitorování v reálném čase, blokování hovorů a analýzy nebo přehledy o výkonu fronty. To zahrnuje mimo jiné ověřování dashboardů a nástrojů pro tvorbu reportů, které poskytují užitečná data o distribuci hovorů, aktivitě agentů a metrikách front.

Lovecké skupiny: Distribuce hovorů

Skupiny pro vyhledávání jsou klíčovým mechanismem pro distribuci hovorů předdefinovaným skupinám uživatelů. Akceptační testování musí potvrdit, že volání jsou směrována členům skupiny na základě nakonfigurovaného algoritmu vyhledávání a že scénáře přetečení, přesměrování a nereagování jsou zpracovávány v souladu s návrhem. Zajištění, aby členství ve skupinách a směrování hovorů odpovídaly dříve stanoveným pravidlům, je nezbytné pro provozní konzistenci a spokojenost uživatelů.

Automatické operátory: Oznámení a ovládání menu

Automatické telefonní operátory představují přední linii automatizovaného vyřizování hovorů. Testování musí zahrnovat přehrávání hlášení, přesnost nahraných pozdravů a správné fungování stromových menu. Volby v menu by měly spolehlivě směrovat volající k příslušným oddělením, jednotlivcům nebo externím číslům. Testování by mělo zahrnovat i neplatné scénáře nebo scénáře vypršení časového limitu, aby se potvrdilo, že volající dostávají jasné pokyny nebo jsou přesměrováni dle očekávání.

Provoz hlasové schránky

A konečně, funkce hlasové schránky je pro uživatelský zážitek zásadní. Akceptační testy by měly ověřit, zda jsou hlasové schránky správně přiřazeny a přístupné, a to jak zvnitro organizace, tak i na dálku. Schopnost nahrávat, načítat a spravovat zprávy musí být potvrzena spolu s doručováním oznámení.

Optimalizovat

Migrace PSTN do Cloud Connect pro

Optimalizace místní infrastruktury

Využívejte analytiku a řešení problémů

Migrace PSTN do Cloud Connect pro

Jakmile jsou všechny koncové body a uživatelé migrováni do cloudového volání, jediným účelem Unified CM je fungovat jako tranzitní bod mezi bránami PSTN a prostřednictvím lokální brány. Odebrání bran PSTN a lokální brány pomocí služby Cloud Connect jako přístupu k PSTN pro všechny uživatele služby Webex Calling má několik výhod, včetně snížení nákladů a zvýšení spolehlivosti. Chcete-li převést místní přístup k PSTN na Cloud Connect pro , postupujte takto:

Cloud Connect pro výběr partnera.

Prohlédněte si seznam partnerů Cloud Connect a vyberte si z dostupných partnerů pro umístění vaší organizace.

Cloud Connect pro ověření.

Před přepnutím přístupu k PSTN pro lokality na Cloud Connect je třeba ověřit a potvrdit připojení k PSTN prostřednictvím vybraného partnera Cloud Connect. Za tímto účelem je nutné zřídit testovací umístění s několika testovacími uživateli zřízenými v tomto testovacím umístění. Přístup k PSTN pro toto testovací umístění je poté nastaven na partnera Cloud Connect před ověřením připojení PSTN pomocí testovacích telefonů. Po úspěšném ověření lze testovací umístění odpojit.

Přenos čísla.

Pro přípravu na přechod na Cloud Connect je třeba zadat objednávku portů pro všechna čísla aktuálně přiřazená k PSTN trunku ukončujícímu na. Všechna čísla je nutné přenést k partnerovi Cloud Connect. Pro zachování dosažitelnosti mezi lokalitami je nutné přenést všechna čísla ze všech lokalit současně.

Přepněte na partnera Cloud Connect.

K datu přechodu na nově poskytovanou technologii je nutné nastavit přístup k PSTN pro všechna místa u poskytovatele cloudově připojené PSTN a ověřit příchozí i odchozí připojení.

Jak je uvedeno v části o PSTN v kapitole o návrhu, zákazníci se mohou také rozhodnout přesunout svůj přístup k PSTN do Cloud Connect na začátku přechodu pomocí trunkingu PSTN pro hybridní nasazení. Další informace naleznete v části Trunkování PSTN pro hybridní nasazení Webex Calling. V takovém případě je během přechodu přístup k PSTN přes lokální bránu a po přesunutí všech uživatelů do není žádný další krok migrace související s PSTN kromě vyřazení z provozu a lokálních bran.

Optimalizace místní infrastruktury

Jakmile budou všichni uživatelé převedeni do cloudové registrace a všechny koncové body budou převedeny do cloudové registrace (nebo budou vyřazeny z provozu), aktualizujte příslušnou místní infrastrukturu nyní, když se používá cloudové volání. Aktualizace infrastruktury zahrnují:

Odeberte z místních serverů DNS záznamy SRV pro řízení volání a zasílání zpráv, včetně cisco_uds._tcp.<domain>, cup_login._tcp.<domain>. Tyto záznamy SRV již nejsou pro vyhledávání klientských služeb nutné.

Odstraňte záznamy SRV DNS související s okrajem sítě z veřejného systému DNS, včetně collab_edge._tls.<domain>. Tyto záznamy SRV již nejsou vyžadovány pro zjišťování klientských služeb v rámci služeb pro spolupráci na okraji sítě.

Aktualizujte všechny relevantní obory DHCP a odeberte možnost 66 a možnost 150. TFTP/boot adresy serverů. Tyto obory již nejsou vyžadovány pro zjišťování a stahování konfigurace řízení volání koncových bodů.

Update/remove vhodné dial-peery v Local Gateway/CUBE které směrují volání do a z Unified CM. Tyto dial-peery již nejsou pro směrování hovorů v místní síti nutné.

Odstranění nebo odstranění všech virtuálních počítačů uzlů clusteru and/or servery. Podle potřeby přehodnoťte výpočetní prostředky a hardware. Tyto zdroje již nejsou potřeba pro řízení hovorů a edge služby.

Odstranění nebo odstranění všech virtuálních počítačů uzlů clusteru and/or servery. Podle potřeby přehodnoťte výpočetní prostředky a hardware. Tyto zdroje již nejsou potřeba pro hlasovou schránku a služby sjednoceného zasílání zpráv.

Úklid: Po migraci přístupu z PSTN do cloudově připojené PSTN lze vyřadit z provozu kmenové linky PSTN, brány PSTN a lokální bránu.

U všech stávajících lokálních řešení E911 odstraňte všechna umístění nebo čísla, která migrovala, a po dokončení úplného přechodu odeberte virtuální počítače nebo servery aplikací. Podle potřeby přehodnoťte výpočetní prostředky a hardware. Tyto zdroje již nejsou potřeba pro tísňová volání a lokalizační služby.

Rozlišovací jména patřící migrovaným uživatelům by měla být umístěna ve skrytém oddílu, aby se předešlo selhání směrování volání a aby se zajistilo, že všechny služby CSS budou mít prioritní přístup ke cloudové cestě stejných rozlišovacích jmen.

Aktualizujte fyzické dispečerské umístění a síťový prvek v Horizon Mobility vždy, když dojde ke změnám. Mezi běžné aktivity, které vyžadují aktualizace, patří:

Výměna síťového přepínače

Výměna bezdrátového přístupového bodu

Změny rozsahu DHCP

Fyzické změny uvnitř budovy (pokud se řeší cubical/office)

Rozšíření nebo zmenšení fyzického kancelářského prostoru uvnitř budovy.

Využívejte analytiku a řešení problémů

poskytuje komplexní analytické funkce a funkce pro řešení problémů, které vám pomohou vizualizovat a sledovat vaše nasazení. Ty zahrnují kvalitu médií, podrobnou historii hovorů, frontu hovorů, vyhledávací skupinu a analýzu automatického telefonního operátora. Příklad analýzy kvality médií je znázorněn na obrázku analýza kvality médií.

analýza kvality médií

V části řešení problémů si lze prohlédnout každý hovor uskutečněný pomocí s podrobnými informacemi o klíčových problémech s kvalitou médií a signalizací, což pomůže přesně určit problémy s médii i neúspěšná volání, jak je znázorněno na obrázku řešení problémů s kvalitou médií.

řešení problémů s kvalitou médií

Řešení problémů lze také integrovat s dalšími produkty Cisco, jako jsou přepínače ThousandEyes a Meraki, a poskytnout tak ještě bohatší integrovaný zážitek v Control Hub. Další informace o používání analytických nástrojů Webex Calling a řešení problémů naleznete v článku Řešení problémů s hovory Webex Calling v Control Hub.

1	Vytvoření vyhrazené synchronizační skupiny: Ve svém podnik ovém adresáři (Microsoft Entra ID nebo AD) vytvořte skupinu zabezpečení speciálně pro synchronizaci (například synchronizační skupinu).
2	Naplnění skupiny cílovými uživateli: Do této skupiny přidejte pouze uživatele, které chcete synchronizovat (například testovací skupinu během pilotní fáze). To vám umožní pevně řídit, kdo je součástí procesu synchronizace.
3	Konfigurace synchronizační smlouvy s filtrováním založeným na skupinách: Při nastavování dohody o synchronizaci v zřizování Directory Connector nebo Entra ID nakonfigurujte rozsah tak, aby zahrnoval pouze uživatele, kteří jsou členy určené skupiny. Pro Microsoft Entra ID můžete v nastavení zřizování použít přiřazení založená na skupinách Pro službu AD můžete definovat filtr LDAP tak, aby zahrnoval pouze uživatele patřící do určené skupiny.
4	Rozbalte skupinu podle potřeby: Jak postupujete do širších fází nasazení, jednoduše přidejte do synchronizační skupiny další uživatele nebo skupiny. Rozsah synchronizace se automaticky rozšíří tak, aby zahrnoval tyto uživatele, což umožní řízené a postupné zavádění. Příklad implementačních kroků: V aktivním adresáři: Vytvořte skupinu zabezpečení s názvem synchronizační skupina. Přidejte požadované pilotní uživatele do této skupiny. Nastavte Directory Connector pomocí filtru LDAP, například: (memberOF=CN=WebEx Sync Group, OU = Groups, DC=YourDomain, DC=COM). Do Microsoftu zadejte ID: Vytvoření skupiny s názvem synchronizační skupina Přiřaďte skupinu k nastavení zřizování v Entra ID Budou zřízeni pouze uživatelé v této skupině. Před aplikací na celou organizaci vždy otestujte synchronizaci založenou na skupinách v neprodukčním prostředí Pravidelně kontrolujte členství ve skupině, abyste zajistili synchronizaci pouze oprávněných uživatelů Pro průběžnou správu automatizujte aktualizace členství ve skupině na základě obchodních pravidel nebo HR systémů, pokud je to možné. Odkazy: Synchronizace uživatelů Entra ID do Control Hub Nastavení aplikace Entra ID Wizard v Control Hubu Adresářový konektor

1	Vytvořte vyhrazenou synchronizační skupinu: V podnikovém adresáři (Microsoft Entra ID nebo AD) vytvořte bezpečnostní skupinu určenou speciálně pro synchronizaci (například skupina synchronizace).
2	Naplňte skupinu cílovými uživateli: Do této skupiny přidejte pouze uživatele, které chcete synchronizovat (například testovací skupinu během pilotní fáze). To vám umožňuje přesně kontrolovat, kdo je zahrnut do procesu synchronizace.
3	Nakonfigurujte synchronizační dohodu s filtrováním na základě skupin: Při nastavování synchronizační smlouvy v Directory Connectoru nebo zřizování Entra ID nakonfigurujte rozsah tak, aby zahrnoval pouze uživatele, kteří jsou členy určené skupiny. Pro Microsoft Entra ID můžete v nastavení zřizování použít přiřazení na základě skupin. Pro službu AD můžete definovat filtr LDAP, který zahrne pouze uživatele patřící do zadané skupiny.
4	V případě potřeby rozbalte skupinu: S postupem k širším fázím nasazení jednoduše přidávejte do synchronizační skupiny další uživatele nebo skupiny. Rozsah synchronizace se automaticky rozšíří o tyto uživatele, což umožní kontrolované a postupné zavádění. Příklady kroků implementace: V aktivním adresáři: Vytvořte skupinu zabezpečení s názvem synchronizační skupina. Přidejte požadované pilotní uživatele do této skupiny. Nastavte Directory Connector s filtrem LDAP, například: (memberOf=CN=Webex Synchronizace Group,OU=Groups,DC=yourdomain,DC=com). V Microsoftu zadejte ID: Vytvořte skupinu s názvem synchronizační skupina Přiřaďte skupinu k nastavení zřizování v Entra ID. Pouze uživatelé v této skupině budou mít přístup k . Synchronizaci založenou na skupinách vždy otestujte v neprodukčním prostředí, než ji použijete v celé organizaci. Pravidelně kontrolujte členství ve skupinách, abyste zajistili, že jsou synchronizováni pouze autorizovaní uživatelé. Pro průběžnou správu automatizujte aktualizace členství ve skupinách na základě obchodních pravidel nebo HR systémů, pokud je to možné. Reference: Synchronizace uživatelů Entra ID do Control Hubu Nastavení aplikace Entra ID Wizard v Control Hubu Konektor adresáře

Cisco AI Assistant

Děkujeme za vaši zpětnou vazbu.

Průvodce nasazením migrace

Než začnete

Přehled

Základní komponenty

Přehled procesů PPDIO

Obecný popis PPDIO

Použití PPDIO pro migrační projekty Unified CM na Webex Calling

Připravit

Plán

Návrh

Implementovat

Optimalizace

PPDIO zpětnovazební smyčky

Migrační přístup

Připravit

Obchodní a technické požadavky

Proč je shromažďování požadavků důležité:

Obchodní požadavky

Technické požadavky

Připravenost a požadavky na síť

Nastavení cloudové komunikace propojené

Posouzení současného prostředí

Licencování

Místa/Stránky

Inventarizace stávajících zařízení/klientů

Ověřte způsobilost zařízení

Uživatelé

Připojení PSTN

Funkce a využití funkcí

Integrace společnosti Cisco: Unity Connection UCCX UCCE

Nahrávání hovorů

Integrace třetích stran

Plán

Plán projektu na vysoké úrovni

Migrační cesta - jeden nebo dva kroky?

Možnost 1: Jednostupňová migrace uživatele

Možnost 2: Migrace uživatele ve dvou krocích

Krok 1

Krok 2

Návrh

Výběr regionu

Lokality

PSTN

Číselný plán

Místní vytáčecí plán v

číselný plán

Nahrávání

1. Výběr poskytovatele nahrávání hovorů

2. Výběr regionu

Tísňové volání

Licencování

Ruční přiřazení přes

Šablony automatického přiřazení licencí

Hromadné přiřazení prostřednictvím šablony CSV

Přiřazení na základě rozhraní API

Požadavky na licenci

Zřizování uživatelů

Skupiny uživatelů

Doporučený přístup při migraci z do

Navrhování skupin uživatelů

Jednotné přihlášení (SSO)

Podpora více IdP

1. Fúze a akvizice

2. Více nezávislých IT oddělení

3. Různé skupiny uživatelů nebo domény

4. Podpora různých autentizačních protokolů

5. Vylepšené zabezpečení a dodržování předpisů

6. Zjednodušené uživatelské prostředí

Duo MFA s SSO pro

Vlastnosti

Automatická obsluha

Zavolejte Park

Vyzvednutí hovorů

Fronta hovorů

Huntská skupina

Provozní režimy

Skupina stránkování

nahrávky