- Hjem
- /
- Artikel
Tak for din feedback.
Vejledning til implementering af migrering
I denne artikel
Har du feedback?Den strukturerede overførselsproces fra Cisco Unified CM i det lokale miljø til skybaseret Webex Calling, ved hjælp af PPDIO-metoden. Dette indebærer kritiske designovervejelser såsom regionvalg, opkaldsplaner, alarmtjenester og opkaldsoptagelse. Processen også indeholder detaljerede oplysninger om licenser, brugerklargøring, SSO og netværksberedskab for at sikre en gnidningsløs og Effektiv overgang.
Før du begynder
Denne vejledning er beregnet til teams eller enkeltpersoner med erfaring med at konfigurere og administrere Cisco Unified Communications Manager (Unified CM) og Cisco-slutpunkter, herunder IP-desktelefoner, videoenheder og Jabber-softwareklienter. I hele dette dokument er der links til produkt- og supportdokumentation, der kan hjælpe.
Dette dokument fokuserer kun på overgange fra Unified CM til Webex Calling multi-tenant. Udtrykket Webex Callingi dette dokument henviser altid til Webex Calling multi-tenant.
Før du begynder migreringen fra Unified CM tilWebex Calling, er det bydende nødvendigt at have en omfattende forståelse af Webex Calling løsningen og dens respektive komponenter. En vellykket migrering kræver kendskab til Webex Calling arkitek turen, servicemodellerne, implementeringsmulighederne og tilknyttede funktioner for korrekt at kortlægge eksisterende Unified CM arbejdsbelastninger og designe en effektiv overgangsplan.
En grundig forståelse af følgende Webex Calling komponenter er afgørende for at informere om en effektiv overgangsstrategi og operationel beredskab.
-
Kontrolhub
-
Klargøring af mapper og brugere
-
Webex Callingplatform
-
Understøttede opkaldsendepunkter
-
PSTN-tilslutningsmuligheder
-
Webex Callingopkaldsplan og nummerstyring
-
Sikkerheds- og overholdelsesfunktioner.
Du kan finde flere oplysninger i Cisco Preferred Architecture forWebex Calling.
Denne vejledning fremhæver værktøjer og processer, der skal bruges gennem hele overgangens livscyklus. En overgang fra opkald i det lokale miljø til en ny cloud-opkaldsplatform kan Webex Calling dog være en betydelig indsats med potentielle forretningsmæssige, tekniske og komplekse udfordringer. Unified CM For at hjælpe med at overvinde disse udfordringer har Cisco et par forskellige muligheder til rådighed for at hjælpe dig med din rejse. Det er vigtigt at gennemgå oplysningerne i Enterprise Cloud-opkald - Overførsel af opkald og forstå hver mulighed, og hvordan hver enkelt mulighed muligvis kan hjælpe dig med din egen overførsel.
-
Webex-migreringsværktøjer: selvbetjente, gratis værktøjer indbygget i Control Hub for at strømline din overgang til Webex Calling
-
Certificerede overførselsudbydere: Cisco-validerede software- og værktøjsudbydere, der har udviklet migreringsløsninger til at hjælpe Webex-partnere og kunder med komplekse og store migreringer. Disse løsninger kan hjælpe med at forenkle, styre og fremskynde overgangen til Webex Calling
-
Webex Setup Assist: en Cisco-ledet migreringstjeneste, der guider kunder og partnere gennem udrulningen Webex Calling og konfigurationen, som er nødvendig for at kunne migrere Unified CM brugere og tjenester til. Webex Calling
Oversigt
Med væksten i cloud-leverede samarbejdstjenester søger flere kunder at flytte deres eksisterende samarbejdsarbejdsbelastninger til skyen i betragtning af løf terne om reducerede samlede ejeromkostninger, forenklet administration, kontinuerlig levering af funktioner, øget skalering og overlegen pålidelighed, der er iboende i skybaserede tjenester. Når kunderne ønsker at foretage overgangen fra lokale samarbejdstjenester til cloud-samarbejdstjenester, er det vigtigt for dem at forstå, hvad overgangen indebærer, og de trin, der kræves for at gennemføre overgangen.
Formålet med dette dokument er at give installationsvejledning til kunder, der specifikt ønsker at skifte fra det lokale miljø Unified CM til Webex Calling i skyen. Denne installationsvejledning antager, at læseren har en grundlæggende forståelse af opkald sovergangen mellem Unified CM ogWebex Calling, herunder hvilke ændringer, der foretages, når denne overgang foretages, og hvad forskellene er, når opkaldsarbejdsbyrden flyttes fra det lokale miljø til skyen. Før du fortsætter, skal du sikre dig, at du har gennemgået og er fortrolig med de oplysninger, der er tilgængelige på overgangskortet. Dette overgangskortdokument indeholder oplysninger om ændringerne og forskellene i denne overgang.
Som vist i figur Samarbejdsarkitektur i det lokale miljø: opkaldsstyring og fjernad gang omfatter en typisk lokal implementering forskellige samarbejdsinfrastruktur komponenter på netværket, en opkaldsstyringsplatform, en kantplatform, hardware- og software slutpunkter og i nogle tilfælde endda konference- og planlægningsplatforme. I Cisco- arkitekturen vil dette omfatte Unified CM opkaldskontrol, Expressway til fjernadgang og business-to-business (B2B) edge-tjenester, Cisco Meeting Server/ Cisco Meeting Management til lokale konferencer, Unity Connection til talemeddelelser og brugerrettet hardware (Cisco IP-telefoner, Cisco Desk- og Room-video systemer) og software () IP-baserede slutpunkter. Cisco Jabber Disse komponenter kan variere lidt i nogle miljøer, men dette er udgangspunktet for overgangen beskrevet i resten af dette dokument.
Arkitekturen vist i figur Samarbejdsarkitektur i det lokale miljø: opkaldsstyring og fjernadgang er baseret på Preferred Architecture (PA) for Cisco Collaboration Enterprise On-Premises Imployments. Du kan finde flere oplysninger om Enterprise On-premise under Ciscos foretrukne samarbejdsarkitekturer.
Før: Tabellen med opkaldsinfrastrukturkomponenter i det lokale miljø viser nøgleelem enterne i arkitekturen Webex Calling i det lokale miljø, før overgangen til skyen.
| Produkt | Beskrivelse |
|---|---|
| Unified CM | Lokal opkaldsstyring, der leverer enhedsregistrering og opkaldsroutingtjenester |
| Cisco Expressway-C/E | Edge-infrastruktur, der leverer mobil- og Remote Access (MRA) og business-to-business (B2B) funktionalitet, der gør det muligt for eksterne slutpunkter at oprette forbindelse sikkert uden for organisationen . Expressway implementeres parvis for at give firewall-kryd sning til eksterne slutpunkter. |
| Cisco mødeserver (CMS), Cisco mødestyring (CMM) og Cisco TelePresence Management Suite (TMS) | Lokal tale-, video- og webkonferenceinfrastruktur, der leverer multipunktmøder, mødestyring og planlægningsfunktioner. [Valgfrit] |
| Cisco Unity Connection | Lokal stemmemeddelelsesplatform, der giver mulighed for telefonsvarer og samlede meddelelsesfunktioner. [Valgfrit] |
| Cisco Desk, Cisco Room, Cisco Board, Cisco IP-telefoner og Cisco Jabber | IP-baserede enheder, der er registreret til Unified CM og giver mulighed for tale- og videoopkald |
Som illustreret i Figur Overgangsbeslutning: Opkald i det lokale miljø Webex Calling kan kunder, der har en lokal opkaldskontrol med Unified CM og skrivebords- og video-IP-slutpunkter, vælge mellem at skifte arkitekturen til en cloud-arkitektur. Webex Calling
Beslutningen skal træffes ud fra kundens funktionalitetskrav. Kunder, der har følgende krav, bør overveje nøje, før de træffer denne beslutning, og kan i sidste ende beslutte at beholde opkaldskontrol i det lokale miljø:
- Telefonmodeller understøttes ikke af Webex Calling
- Komplekse eller talrige integrationer med andre lokale systemer eller løsninger, især hvor Webex Calling det er vanskeligt at replikere disse integrationer med, eller der ikke findes tilsvarende alternative løsninger
- Kompleks opkaldsplan, meget detaljerede serviceklasser eller begge dele
- Begrænset, begrænset eller upålidelig internetadgang
- Strenge databeskyttelses- og ejerskabspolitikker
- Overholdelseskrav for medieoptagelse og -lagring i det lokale miljø eller i landet
- Tredjepartsintegrationer uden levedygtig alternativ integration Webex Calling
- Kontaktcenterintegrationer, hvor kontaktcenterinteren endnu ikke flytter til sky en.
Dette dokument fokuserer på kunder med udrul Unified CM ninger af opkaldskontrol, der ønsker at forstå de generelle trin, overvejelser og krav til aktivering af Webex Calling udrulning som beskrevet i næste afsnit.
Kernekomponenter
Målarkitekturen for denne migrering omfatter flere nye komponenter. Dette omfatter Webex Calling tjenesten til skybaseret opkald, Webex App, Cisco Directory Connector til identitetsintegration og Local Gateway (LGW) til PSTN- adgang samt integration af opkald i det lokale miljø til skyen. Cisco-opkaldsplaner eller Cloud Connec ted PSTN (CCP) faciliteret af en Cloud Connect for Webex Calling partner er yderligere muligheder for PSTN-adgang.
Som vist i Figur Efter: Webex Calling Arkitektur føjes de nye komponenter (Webex Calling, Katalogforbindelse, Lokal gateway og Overlevelses-gateway) til den eksisterende installation i det lokale miljø.
Efter: Tabellen over cloud-opkaldsinfrastrukturkomponenter viser de nye elementer i arkitekturen efter overgangen til Webex.
| Produkt | Beskrivelse |
|---|---|
| Webex Calling | Cloud-baseret opkaldstjeneste leveret fra Webex-platformen og leverer slutpunktregistrering og opkaldsrouting |
| Cisco Directory-stik | Windows-program, der kører på en Windows-domænemaskine, der leverer identitet
ssynkronisering mellem virksomheden i det lokale miljø Active Directory og identitetsl
agringen i Webex-organisationen. For kunder, der flytter fra det lokale miljø Active Directory til Entra ID, bruger identitetsintegrationen med Webex i stedet for Cisco Directory Connector appen Entra ID Wizard. |
| Lokal gateway | En lokal gateway fungerer som en bro mellem en kundes samlede kommunikationsnetværk i det lokale miljø og Webex Calling skyen. Det kan implementeres lokalt eller hostes af en partner, hvilket giver PSTN- adgang til cloud-registrerede slutpunkter samt opkaldsintegration mellem registrerede og cloud- Unified CM registrerede slutpunkter. Cisco IOS-XE Integrated Services Router (ISR 1100- og 4000-serien), Cisco Catalyst 8200/8300-serien, Cisco Catalyst 8000V Edge- software og forskellige certificerede tredjeparts Session Border Controllers (SBC'er) kan bruges som LGW til en trinvis migrationsmetode. |
| Gateway til overlevelsesevne | Survivability Gateway (SGW) er en lokal IOS-XE-baseret gateway, der leverer fallback-opkaldstjenester til slutpunkter på stedet Webex Calling under netværksafbrydelser. |
| Cisco-opkaldsplan, Cloud Connect til Webex Calling | Cisco Calling Plan og Cloud Connect for Webex Calling er skybaserede muligheder for PSTN-adgang til Webex Calling slutpunkter. PSTN-adgang lettes af en PSTN-udbyder i skyen og kræver intet udstyr i det lokale miljø. |
| Webex-appen | Klientapplikation, der kører på desktop OS (Windows, Mac) eller mobilt OS (Android, iOS) og registreres direkte på Webex Calling platformen for opkaldsfunktionalitet. |
PPDIO procesoversigt
PPDIO- processen står for Forbered, Planlæg, Design, Implementér og Optimér. Det er en struktureret Cisco-metode, der guider projekter fra indledende vurdering til kontinuerlig forbedring, hvilket sikrer effektive og vellykkede implementeringer eller migreringer.
Generel beskrivelse af PPDIO
-
Forbered dig: Vurder det nuværende miljø, indsaml krav, og tilpas interessenter for at etablere et solidt fundament.
-
Plan: Udvikle detaljerede projektplaner, herunder tidslinjer, ressourcer og risikobegrænsende strategier.
-
Design: Arkitekt målløsningen skræddersyet til forretningsmæssige og tekniske behov.
-
Implementere: Udfør implementeringen eller migreringen i henhold til designet, validering af funktionalitet og ydeevne.
-
Optimer: Forbedre løsningen løbende efter implementeringen ved at overvåge ydeevne, forfine konfigurationer og udnytte automatiserings- og integrationsværktøjer.
Brug af PPDIO Unified CM til Webex Calling migreringsprojekter
Ved overgangen fra Unified CM til Webex Calling giver PPDIO-processen en klar køreplan for at sikre en smidig og effektiv overgang:
Forbered
-
Vurdere det eksisterende Unified CM miljø og migrationsberedskab
-
Indsamle detaljerede data om brugere, enheder, netværk og afhængigheder
-
Indsamle placeringsoplysninger, herunder nødberedskabsadresse, antal brugere, internet adgang, PSTN-adgang
-
Identificer risici og definer projektomfang for at tilpasse alle interessenter.
Planlæg
-
Opret en omfattende overførselsplan med batchplaner, ressourcetildelinger og tidslinjer
-
Definer opgaver som enhedens firmwareopgraderinger, licensklarering og bruger onboarding
-
Koordiner migreringsvinduer med Cisco og partnere for at minimere forstyrrelser.
Udformning
-
Kortlæg aktuelle Unified CM konfigurationer, opkaldsplaner og brugerprofiler til Webex Calling ækvivalenter
-
Design Webex Calling miljøet, herunder PSTN-strategi (midlertidig og endelig), placeringer, brugerroller og integrationspunkter som Local Gateway (CUBE) og mappesynkronisering
-
Planlæg for sameksistensscenarier, hvor Unified CM og Webex Calling fungerer samtidigt under migrering.
Implementere
-
Brug Control Hub-migreringsværktøjer sammen med tredjepartsværktøjer til at udføre ændringer i enhedens firmwaretilstand, funktionskonfiguration og brugermigreringer
-
Anvend masseoperationer og klargøring ved hjælp af Webex API'er til at strømline store overførsler og konfigurationer
-
Udfør licensudstedelse, enhedsregistrering og konfigurationsopdateringer
-
Valider overførselssucces gennem test og operationel verifikation.
Optimer
-
Kontinuerlig overvågning af Webex Calling ydeevne og brugeroplevelse
-
Begræns konfigurationer og arbejdsgange baseret på driftsdata og feedback
-
Udnyt automatiserings- og integrationsfunktioner til at forbedre effektiviteten og skalerbarheden
-
Afmontere ældre Unified CM komponenter efter behov og yde løbende støtte til dag-2-operationer.
Denne forbedrede PPDIO-tilgang sikrer en kontrolleret, gennemsigtig og effektiv migration fra Unified CM til ved at udnytte Ciscos værktøjerWebex Calling, API'er og partnerøkosystem til at opretholde forretningskontinuitet og forbedre samarbejdsfunktioner.
PPDIO feedbacksløjfer
Oversigten på højt niveau afbildet i figur iterationer under udførelse af PPDIO illustrerer en enkelt feedback-loop fra optim eringsfasen tilbage til forberedel sesfasen. Dette betyder, at der efter den indledende implementering er en løbende mulighed for løbende forbedringer. Hver optimeringscyklus kan identificere nye krav eller områder til forbedring, som kan løses gennem efterfølgende projekter eller initiativer. Disse individuelle projekter følger til gengæld hver den etablerede PPDIO (Prepare, Plan, Design, Implement, Optimize) livscyklus. Denne iterative tilgang sikrer, at systemet forbliver på linje med udviklende forretningsmål og teknologiske fremskridt, hvilket fremmer en kultur med løbende forfining og tilpasningsevne.
Under udførelsen af PPDIO-processen er det almindeligt, at resultater i de senere faser nødvendiggør revurdering og potentielt revision af beslutninger truffet i tidligere faser. For eksempel kan problemer, der opstår i gennemførelsesfasen, såsom identifikation af uklar heder i designet eller manglende detaljer, afsløre, at visse aspekter ikke blev behandlet fuldt ud i designfasen. I sådanne tilfælde bliver det nødvendigt at gentage tilbage til den relevante tidligere fase for at løse disse problemer, før du fortsætter. Denne iterative feedback mekanisme, som illustreret i figur Unified CMassisteret PPDIO-proces, sikrer, at løsningen er grundigt valideret og raffineret, hvilket i sidste ende bidrager til en mere robust og effektiv implementering.
Når der foretages en overgang fra Unified CM tilWebex Calling, kan hver fase af PPDIO-processen drage stor fordel af information indsamlet fra det eksisterende Unified CM miljø. For eksempel kan omfattende opgørelser over brugere, telefonnumre, opkalds funktioner og opkaldsplankomponenter ekstraheres fra den aktuelle Unified CM konfiguration. Disse data supplerer oplysninger leveret direkte af interessenter og hjælper med at strømline planlægnings- og designaktiviteter. Udnyttelse af passende værktøjer til at automatisere data ekstraktion og analyse forbedrer ikke kun nøjagtigheden, men fremskynder også den overordnede proces. Ved at udnytte indsigt fra den eksisterende implementering Webex Calling kan overgangen til udføres mere effektivt end en traditionel greenfield-implementering, mens den stadig over holder den strukturerede PPDIO-metode. Denne proces er illustreret i figur Unified CMassisteret PPDIO-proces.
Migrationsmetode
Når du planlægger din overgang fra det lokale miljø Unified CM til det lokale Webex Calling miljø, skal du bestemme, hvordan du vil forholde dig til denne rejse. Først skal du beslutte, om migr eringen vil være en flash-cut (alt på én gang) eller en trinvis tilgang (migrere grupper af brugere/enheder over en længere periode).
Hvis du foretager en flash-cut- overførsel, flytter alle dine brugere og enheder hurtigst muligt. Med denne metode flytter du alle brugere og enheder fra det lokale miljø Unified CM til Webex Calling på samme tid. I det væsentlige er det et enkelt migreringsvindue for alle brugere og enheder. Når denne migrering er afsluttet, vil alle dine brugere og enheder være på Webex Calling platformen, og al din Unified CM infrastruktur kan tages ud af drift. Mange organisationer kan dog ikke bruge denne tilgang på grund af omfanget og størrelsen af deres opkaldsinstallation.
Den anden tilgang er en tr invis migration. De fleste organisationer vil bruge denne tilgang, da den giver bedre kontrol, styring og skalering med migreringen. Det er også bedre egnet til større UC-implementeringer og/eller implementeringer på tværs af flere regioner. Derfor fokuserer dette dokument på den trin vise tilgang med to trin i overgangen.
Som vist i nedenstående figur Trinv is opkaldsovergang: Hybrid og cloud resulterer den første overgangsfase (fase 1) i en sameksistensimplementering med dobbeltopkaldsmiljøer. I denne fase overføres nogle brugere, enheder og bløde klienter til, Webex Calling mens andre stadig er på opkaldskontrollen i det lokale miljøUnified CM. Den sidste overgangsfase (fase 2) resulterer i et rent cloud-opkald smiljø, hvor alle brugere, enheder og bløde klienter er blevet fuldt overgået til Webex Calling platformen.
Hvor lang tid det tager en organisation at skifte helt til cloud-opkald varierer afhængigt af dens aktuelle implementering. I nogle tilfælde kan en organisation foretage den indledende overgang og forblive i sameksistensfasen med dobbelt opkaldskontrol (fase 1) i en længere periode (måneder eller endda år), mens en organisation i andre tilfælde kan overgå fuldt ud til Webex Calling (fase 2) i en meget kort periode (uger eller måneder). Dette dokument er beregnet til at dække begge faser (fase 1 - sameksistens og fase 2 - fuldstændig overgang).
Det er muligt, at nogle organisationer kan opretholde en sameksistens med dobbelt opkaldskon trol på ubestemt tid uden planer om nogensinde at overgå fuldt ud til cloud-opkald.
Den anden overvejelse er, hvordan du overfører brugere, enheder og bløde klienter fra den lokale op kaldskontrol til cloud-opkaldskontrollen. Den anbefalede tilgang er en 3-trins overgang. Figuren Anbefalet 3-faseovergang nedenfor opdeler denne tilgang i de 3 faser.
Før migrering: Denne fase fokuserer på at gøre både Webex og Unified CM miljøer klar til migreringen. Dette handler ikke om at kalde specifik planlægning eller konfigurationer og fokuserer på at gennemføre aktiviteter, der kan udføres nu og før et Webex Calling migrationsprojekt starter. Målet er at bygge fundamentet for, at de to miljøer kan forberede sig på migrationen.
Migrationsforberedelse: Denne fase begynder indsatsen for at forberede migreringen til Webex Calling. Her skal forretningsmæssige og tekniske krav gennemgås og opdateres. Gør ikke bare et løft og skift af det, der i øjeblikket implementeres med, Unified CM og omdefiner i stedet de forretningsmæssige og tekniske krav, som din virksomhed har brug for i dag og i fremtiden ved at udnytte kraften i. Webex Calling Derudover er dette den fase, hvor du vil fuldføre dit design, konfigurations planlægning og migrationsplanlægning/tidsplan.
Migrering (udrulning og nedlæggelse): Denne fase er, hvor den faktiske migrering af brugere, enheder, telefonnumre og bløde klienter finder sted. Som diskuteret ovenfor kan denne fase afsluttes for alle på én gang (flash-cut) eller over flere ændringsvinduer (fas e-cut). Slutbrugerens adoptionsplaner, uddannelse og kommunikation er afgørende, så dine brugere er opmærksomme på ændringerne, hvordan de bruger den nye opkaldsplatform, og ved, hvornår æn dringen vil ske. Det sidste trin er at deaktivere al den lokale UC-infrastruktur , der ikke længere bruges.
Fasen før migrering indeholder aktiviteter (påkrævet, anbefalet og valgfrit), som du kan begynde at arbejde på med det samme. Det anbefales at gennemføre disse før snarere end senere og helst inden dit projekt begynder. Nogle af aktiviteterne kan tage længere tid at gennemføre, og at starte dem tidligere vil hjælpe med at strømline dit faktiske migreringsprojekt.
Figuren Præmigrationsaktiviteter nedenfor fremhæver fem specifikke kategorier af aktiviteter, der er relateret til en Webex Calling migration.
Forbered
Forretningsmæssige og tekniske krav
Når du planlægger en migrering fra til, er det afgørende at indsamle både tekniske og forretningsmæssige krav grundigt i planlæg ningsfasen. Dette trin sikrer, at migrering stemmer overens med organisationens operationelle mål og tekniske muligheder, hvilket minimerer risici og forstyrrelser.
Hvorfor indsamling af krav er vigtigt:
-
Justerer forretningsmæssige mål: Forståelse af forretningsbehov hjælper med at skræddersy migreringen til at understøtte vigtige arbejdsgange, brugeroplevelse og vækstplaner.
-
Sikrer teknisk kompatibilitet: Identificering af tekniske krav tidligt forhindrer integrationsproblemer med eksisterende infrastruktur, netværk og slutpunkter.
-
Letter ressourceplanlægning: Klare krav hjælper med at estimere tidslinjer, omkostninger og nødvendige ressourcer nøjagtigt.
-
Reducerer risici: Tidlig opdagelse af potentielle udfordringer giver mulighed for proaktive løsninger, hvilket reducerer nedetid og serviceafbrydelser.
Forretningskrav
Typiske forretningskrav omfatter:
-
Antal brugere og placeringer, der skal overføres
-
Ønskede funktioner og tjenester (eksempel opkaldsrouting, voicemail, konferencer, automatiske telefonsvarere, op kaldskøer)
-
Overholdelses- og sikkerhedspolitikker
-
Budgetbegrænsninger og omkostningsforventninger
-
Brugeruddannelse og supportbehov
-
Overvejelser om migrationstidslinje og forretningskontinuitet.
Indsamling af ønskede funktioner og tjenester er et kritisk skridt for at sikre, at det nye system opfylder forretningsbehov. Når du samler disse krav, er det vigtigt ikke kun at overveje, hvad der aktuelt er konfigureret i, men forsøge at indsamle de faktiske krav fra de forretningsenheder, der skal bruge systemet. Ellers er der risiko for, at planen er baseret på langfristede antagelser. Sørg for at evaluere yderligere eller forbedrede funktioner, der er tilgængelige i, som muligvis ikke findes i, såsom skybaserede opkald, avancerede opkaldskøer, , og. Dette hjælper med at udnytte de fulde fordele ved skyplatformen.
Når du evaluerer den aktuelle konfiguration i, er det vigtigt at erkende, at ikke alle eksisterende indstillinger muligvis forbliver nødvendige på grund af skiftende krav gennem hele systemets livscyklus. Fokus bør være på kun at identificere og bevare de konfigurationer, der stemmer overens med de nuværende og fremtidige behov for implementeringen.
Fokuser mere på det, du har brug for, end hvad du har.
Overholdelses- og sikkerhedspoliti kker er vigtige overvejelser under overfør slen fra Webex Calling til for at sikre, at det nye skybaserede kommunikationssystem overholder juridiske, lov givningsmæssige og organisatoriske standarder.
-
Overholdelse af lovbestemmelser: Organisationer skal kontrollere, at de overholder branchespecifikke regler såsom GDPR, HIPAA eller SOX, og imødekommer krav til databeskyttelse, opbevaring og håndtering samt landespecifikke mandater relateret til dataopholdssted, bompengeomgåelse og medielokalitet.
-
Datasikkerhed: Sikring af, at tale- og signaldata krypteres både under transit og i hvile for at beskytte mod aflytning eller uautoriseret adgang.
-
Adgangskontrol: Definere og håndhæve brugergodkendelse, autorisation og rollebaseret adgang for at forhindre uautoriseret brug af kommunikationsressourcer.
-
Revision og overvågning: Implem entering af logning og overvågningsfunktioner til at spore adgang og brug til overholdelsesrevisioner og undersøgelser af sikkerhedshændelser.
-
Politiktilpasning: Til pasning af migreringen til eksisterende virksomhedssikkerhedspolitikker, herunder slutpunktssikkerhed, netværkssegmentering og hændelsesberedskabsplaner.
-
Leverandørsikkerhedsforsikring: Evaluering af Ciscos sikkerhedscertificeringer og overensstemmelsesattester for at sikre pålidelighed.
Håndtering af disse overholdelses- og sikkerhedspolitikker i planlægningsfasen hjælper med at mindske risici, undgå juridiske sanktioner og bevare integriteten og fortroligheden af kommunikationen under og efter migreringen.
Brugeruddannelse og supportbehov er vigtige komponenter under migreringen fra til for at sikre en gnidningsløs overgang og brugeradoption. De vigtigste overvejelser omfatter:
-
Træningsprogrammer: Ud vikle skræddersyede træningssessioner til forskellige brugergrupper (slutbrugere, administratorer, helpdesk-personale) for at gøre dem bekendt med funktioner, brugergrænseflader og nye arbejdsgange.
-
Dokumentation: Giv klare, tilgængelige brugervejledninger, ofte stillede spørgsmål og hurtigt referenc emateriale, herunder Nyheder og Forskel lige ressourcer og trinvise før- og efter -vejledninger (i video- eller hurtigguideformat) for at støtte brugerne, når de tilpasser sig den opdaterede oplevelse efter migrationen.
-
Ændringsstyring: Kommuniker ændringer proaktivt for at styre brugernes forventninger og reducere modstanden.
-
Supportstruktur: Opret et dedikeret supportteam eller en eskaleringssti for at løse brugerproblemer hurtigt under og efter migreringen.
-
Løbende uddannelse: Planlæg løbende uddannelsesopdateringer, når nye funktioner eller opdateringer fri gives i.
-
Feedbackmekanismer: Implementere kanaler, hvor brugerne kan rapportere problemer og give feedback for at forbedre trænings- og supportprocesser.
Håndtering af disse trænings- og supportbehov i planlægningsfasen hjælper med at minimere forstyrrelser, forbedrer brugernes tillid, og maksimerer fordelene ved at migrere til.
Tekniske krav
Flere vigtige tekniske krav skal indsamles og dokumenteres for en vellykket over gang fra til, herunder oplysninger om:
-
Netværksberedskab og båndbreddekapacitet
En omfattende netværksvurdering er afgørende for at sikre, at din eksisterende infrastruktur kan understøtte det nye Webex Calling miljø. Dette omfatter:
-
Båndbreddeanalyse: Evaluering af nuværende og projiceret båndbreddebrug til håndtering af tale-, video- og datatrafik uden overbelastning.
-
Quality of Service (QoS): Implementering af QoS-politikker for at prioritere taletrafik og minimere ventetid, jitter og pakketab.
-
WAN- og internetforbindelse: Kontrol af, at WAN-links og internet forbindelser opfylder kravene til cloud-baserede opkald, herunder redundans- og failover-funktioner.
-
Firewall- og NAT-konfiguration: Sikring af, at firewall- og NAT-indstillinger tillader påkrævet signalering og medietrafik for.
-
-
Integration med eksisterende system
Problemfri integration med eksisterende forretningssystemer er afgørende for brugeroplevelsen og kontinuiteten i arbejdsgangen:
-
Katalogtjenester: Vur dering af integration med en virksomhedskatalog til automatiseret brugerklargøring og godkendelse.
-
CRM- og forretningsapplikationer: Identificering af integrationspunkter med kunde forholdsstyringssystemer og andre forretningskritiske applikationer.
-
Legacy PBX-samarbejdning: Planlæg ning af sameksistens eller fasede migrations strategier, hvis der forbliver ældre telefonisystemer under overgangen.
-
-
Slutpunktskompatibilitet og klargøring
Alle slutpunkter, herunder bordtelefoner, softphones og mobile enheder, skal evalueres for kompatibilitet:
-
Enhedssupport: Bekræfter, at eksisterende IP-telefoner og enheder understøttes af eller identificerer nødvendige udskiftninger.
-
Klargøringsprocesser: Etabler ing af automatiserede eller strømlinede klargøringsm etoder til effektiv onboarding af slutpunkter.
-
Firmware- og softwareopdateringer: Planlægning af nødvendige opdateringer for at sikre interoperabilitet og sikkerhed.
-
-
Sikkerhedskonfigurationer og krypteringsstandarder
Sikkerhed er altafgørende i cloud-kommunikation:
-
Kryptering: Håndhævelse af ende-til-ende-kryptering til signalering og mediestrømme i overensstemmelse med Ciscos bedste praksis for sikkerhed.
-
Godkendelse og adgangskontrol: Implementering af sikre godkendelses mekanismer (såsom SSO, multifaktorgodkendelse) og granulær brugeradgang skontrol.
-
Overholdelse: Sikring af, at løsningen opfylder relevante lovgivningsmæssige og brancheoverholdelsesstandarder (f.eks. GDPR, HIPAA).
-
Sikkerhedsovervågning: Integration med SIEM-værktøjer og opsætning af advarsler om potentielle sikkerhedshændelser.
-
| Krav | Vigtige overvejelser |
|---|---|
| Netværksberedskab og båndbredde | Båndbredde, QoS, WAN/Internet, Firewall/NAT |
| Integration med eksisterende systemer | Vejviser, CRM, PBX, E-mail/kalender |
| Slutpunktskompatibilitet og klargøring | Enhedsunderstøttelse, klargøring, firmwareopdateringer |
| Sikkerhedskonfigurationer og kryptering | Kryptering, godkendelse, overholdelse, sikkerhedsovervågning |
| Brugeruddannelse og forandringsstyring | Træningsprogrammer, dokumentation, forandringskommunikation |
| Nummerportabilitet og opkaldsplan | Nummermigrering/-portering, oversættelse af opkaldsplan |
| Tredjepartsintegrationer | Personsøgning, kontaktcenter, fax, analoge enheder |
Netværksberedskab og krav
Netværksberedskab er afgørende for en vellykket migrering til enhver skybaseret opkaldsløsning som f.eks. Dårlig netværksplanlægning kan føre til forringet opkaldskvalitet, tabte opkald og utilfredse brugere. Kunder skal foretage en netværksvurdering, før de migrerer til. Det anbefales at bekræfte tilgængeligheden af netværksbåndbredde for forventet opkalds volumen, sikre, at kravene til servicekvalitet (QoS) er opfyldt, og forstå de forskellige porte, der skal åbnes i kantfirewallen (e).
Pålidelig netværksforbindelse med tilstrækkelig servicekvalitet (båndbredde, pakketab, RTT) er et grundlæggende krav for at sikre den bedst mulige brugeroplevelse fra ende til ende for alle tale- og videokompatible slutpunkter, klienter og applikationer, der bruger.
Kunder og partnere har adgang til tilslutningsmuligheder ud over OTT-internet (Over-the-Top) , der kan optimere forbindelsen til at inkludere Webex Edge Connect. Du kan finde flere oplysninger om Webex Edge Connect- designdetaljer i Cisco Preferred Architecture for Webex Edge Connect forWebex Meetings, Calling Multi-Tenant og Dedicated Instance.
Kunder kan bruge cScan til netværksvurdering, som giver information om kundens netværkskvalitet, hvor mange opkald der kan etableres, ventetid osv. Du kan finde flere oplysninger om cScan-værktøjet under Brug cScan til at teste Webex Calling netvær kskvaliteten.
For at sikre, at netværket er klar til migrering til, skal du overveje følgende tjekliste:
-
Båndbredde planlægning
Beregn samtidige opkald pr. websted for at sikre, at du har tilstrækkelig opstrøms- og downstream-båndbredde og medtag plads til anden forretningskritisk trafik og fremtidig vækst.
Tabellen for beregning af båndbredde for op kaldstype viser de tilgængelige opkaldstyper med en implementering sammen med den codec og den maksimale båndbredde, der kræves for hver opkaldstype. Webex Calling Som vist i tabellen for beregning af båndbredde for op Webex Calling kaldsty pe, kan den krævede lydopkaldsbåndbredde for hver opkald stype beregnes ved hjælp af følgende generelle formel:
Antal forventede samtidige opkald * Båndbredde pr. opkald baseret på codec = Påkrævet netværkshastighed.
Tabel 2. Webex Callingopkaldstype båndbredde beregninger Opkaldstyper Codec - båndbredde Båndbreddeberegninger /Skrivebordstelefon -> OPUS - 70 kbps Antal samtidige opkald* 70 kbps = Påkrævet netværkshas tighed /Skrivebordstelefon -> Skrivebordstelefon OPUS — 70 kbps Antal samtidige opkald* 70 kbps = Påkrævet netværkshas tighed /Skrivebordstelefon -> PSTN via LGW G.711 — 80 kbps Antal samtidige opkald* 80 kbps = Påkrævet netværkshas tighed /Skrivebordstelefon -> PSTN via Cloud PSTN (f.eks. Cisco-opkaldsplan) G.711 — 80 kbps Antal samtidige opkald* 80 kbps = Påkrævet netværkshas tighed /Skrivebordstelefon -> Enterprise via LGW G.722 — 80 kbps Antal samtidige opkald* 80 kbps = Påkrævet netværkshas tighed /Skrivebordstelefon -> voicemail OPUS — 70 kbps Antal samtidige opkald* 70 kbps = Påkrævet netværkshas tighed Ved at opsummere den samtidige krævede netværkshastighed pr. op kaldstype kan det samlede potentielle båndbreddebehov for et bestemt websted bestemmes.
Alle opkaldsben er altid forankret på adgangsSBC'erne. For at bestemme den nødvendige internetbåndbredde for en given placering skal ikke kun interlokationsopkaldene overvejes , men også intra-lokationsopkald og opkald til og fra en lokal gateway på det pågældende sted. For eksempel vil et intra-site-opkald mellem to MPP-telefoner kræve op til 2 x 70 kbps fuld duplex på stedets internetadgang.
Tabellen med eksempler på Webex Calling båndbreddeberegning viser et eksempel på en komplet båndbred deberegningsøvelse, forudsat at alle enheder er på det samme sted.
Tabel 3. Webex Calling eksempler på beregning af båndbredde Opkaldstyper Antal samtidige opkald Samlet båndbredde Webex-app/skrivebordstelefon → Webex-app 15 2 * 15 * 70 kbps = 2.100 kbps Webex-app/skrivebordstelefon → Skrivebordstelefon 15 2 * 15 * 70 kbps = 2.100 kbps Webex-app/skrivebordstelefon → PSTN via LGW 50 2 * 50 * 80 kbps = 8.000 kbps Webex-app/skrivebordstelefon → PSTN via Cloud Connect til Webex Calling 0 0* 80 Kbps Webex-app/skrivebordstelefon → Enterprise via LGW 15 2 * 15 * 80 kbps = 2.400 kbps Webex-app/skrivebordstelefon → Voicemail Webex Calling 5 5 * 70 kbps = 350 kbps Samlede opkald/Båndbredde 100 opkald 14.950 kbps/14,95 Mbps -
Alle båndbreddeværdier i ovenstående tabeller henviser til IP-båndbredde. Linkbåndbredde er højere afhængigt af WAN-indkapslinger.
-
Båndbredden i ovenstående tabeller er til lydop kald. For båndbredde til videoopkald understøtter Webex App og MPP 8845/65-telefonerne H.264-video med en maksimal opløsning på 720p ved en maksimal båndbredde på 1.500 kbps pr. opkald. Imidlertid vil mængden af båndbredde, der forbruges på et hvilket som helst tidspunkt under opkaldet, svinge baseret på variabel bithastighed, der er forbundet med videok ommunikation.
-
-
Servicekvalitet (QoS)
Implementer QoS-politikker i dit lokale miljø for at prioritere trafik i realtid og sikre, at QoS opretholdes på tværs af switche, routere og firewalls.
-
Mål for latens, jitter og pakketab
Følgende tærskler anbefales for optimal stemmekval itet, når opkald går over-the-top (OTT) og på tværs af internettet :
-
Latens - mindre end 100 ms envejs
-
Jitter - mindre end 10 ms
-
Pakketab - 0,5% eller mindre.
-
-
Firewall og NAT
Sørg for, at firewallen er konfigureret til at tillade trafik som angivet i artiklen, der er tilgængelig under Portreferenceoplysninger for Webex Calling. Tillad desuden adgang til domæner og IP-områder, der er anført i den samme guide, og undgå SIP ALG, da det forstyrrer SIP-signalering. Medietrafik gennem proxyer bør undgås.
-
DNS og NTP
Sørg for korrekt DNS-opløsning af domæner og pålidelige NTP-servere for at synkronisere enhedsur til TLS-certifikatverifikation og logføring.
-
Failover-planlægning
Overvej eksisterende udbyderdataforbindelser (MPLS, SD-WAN osv.), og planlæg generelt direkte internetadgang på hvert sted i din installation. Planlæg redundante internet forbindelser, hvor høj tilgængelighed er påkrævet. Fordi du vil forbruge skybaserede tjenester, er pålidelig internet forbindelse med tilstrækkelig båndbredde et basis krav. Du bør overveje at foretage denne overgang, hvis din organisations lokationers internetforbindelse (er) generelt ikke er pålidelige med lav ventetid og tilstrækkelig op- og downstream-gennemstrømning.
-
Webstedets overlevelsesevne
Webstedsoverlevelsesevne sikrer, at din virksomhed altid er tilgængelig, selvom din netværksforbindelse går i stykker. Site Survivalability bruger en gateway i dit lokale netværk til at levere en reserveopkaldstjeneste til slutpunkter på stedet i situationer, hvor netværksforbindelsen går i stykker. Overvej webstedets overlevelsesevne med en lokal Survivalability Gateway (SGW), hvis forretningskrav kræver kontinuerlig opkald i tilfælde af netværksafbrydelse. For mere information om kontrol af webstedets overlevelsesevne, se Web stedets overlevelsesevne for. Webex Calling
Opsætning af cloud-forbundet UC
Cloud Connected UC (CCUC) er en skybaseret styrings- og analyseløsning designet til at give centraliseret synlighed, administration og indsigt i implementeringer både i det lokale miljø (f.eks.) og cloud (Unified CM). Det fungerer som en bro mellem traditionelle lokale miljøer og Ciscos cloud-tjenester og understøtter organisationer gennem hele migrations rejsen fra til.
Under overgangen til spiller CCUC en afgørende rolle i strømliningen af migreringsprocessen ved at lette ind samlingen af omfattende data fra den eksisterende Unified Communications-implementering. CCUC hjælper med vigtige overgangsopgaver såsom migrering af enheder, funktioner og bruger kontakter, samt automatisering af firmwareopdateringer til understøttede IP-telefoner. Ved at give centraliseret synlighed og styring hjælper CCUC med at sikre en jævnere og mere effektiv migrationsoplevelse.
Cisco anbefaler stærkt, at CCUC implementeres og implementeres tidligt i overgangsprojektet, ideelt før eller under forberedelsesfasen. Dette giver dig den indsigt og de funktioner, der er nødvendige for grundigt at vurdere, opbevare og planlægge efterfølgende migrering saktiviteter og starte din rejse til og fremtidige hybridfunktioner.
Vurdering af det nuværende miljø
En vigtig aktivitet i planlægningen af din overførsel er at vurdere det aktuelle lokale miljø og implementering. Dette giver indsigt i, hvilke potentielle ændringer der kan være nødvendige for en vellykket overgang til. Det giver dig også mulighed for at vurdere nøgleelementerne i platformen i forhold til den eksisterende installation i det lokale miljø. Du kan bruge disse oplysninger til at identificere, hvilke specifikke opgaver der kræves til overgangen, og hvilke ændringer du vil foretage for at opfylde dine forretningsmæssige og tekniske krav og brugssager.
Følgende aspekter er vigtige at gennemgå som en del af denne indsats.
Licensering
Forståelse af den nuværende licensstruktur for den eksisterende implementering er nøglen, når du forbereder dig på at migrere til. Udfør en licensvurdering af følgende områder af din eksisterende Cisco-on-premises løsning.
-
Platformen
Evnen til fuldt ud at formulere, hvad der i øjeblikket er licenseret på din kerneplatform, vil være afgørende, når du arbejder med dit kontoteam eller partner for at bestemme den bedste vej til fleksibel licensering . er licenseret ved hjælp af flex-licensering. Du kan finde flere oplysninger om flexlicensering i Cisco Collaboration flex plan.
-
Brugere og enheder
Identificer, hvilken licenskategori dine eksisterende brugere og enheder kræver. Dette vil blive brugt til at bestemme, hvilken type licens der kræves for brugerne og enhederne. tilbyder flere licenstyper, herunder Professional- og Standard-licenser til brugere og Professional- og fællesområdelicenser til arbejdsområder. Du kan finde flere oplysninger om enhedslicenser i det datablad, der er tilgængeligt på Enhedslicenser.
-
Lokal gateway
Hvis Cisco Unified Border Element (CUBE) er påkrævet for PSTN-adgang til denne overgang, skal CUBE-licensering også overvejes. CUBE-licensovervejelser er dækket senere i dette dokument.
Placeringer/Steder
Antallet og typerne af websteder (store centrale, regionale, filialer osv.) inden for din eksisterende implementering bør overvejes, når du planlægger denne overgang. En fuld forståelse af de eksisterende implementeringssteder vil hjælpe med strategisk planlægning for en vellykket overgang, især når det kommer til at bestemme, hvilke websteder der skal migreres og i hvilken rækkefølge. Forståelse af detaljerede krav til opkaldsplan (nummerering, opkaldsvaner, begrænsningsklasser osv.), webstedsnetværksforbindelse og båndbredde (internet, WAN, LAN) og PSTN-adgang (lokal eller centraliseret, IP eller TDM) for hvert websted vil være afgørende, når der træffes migrationsbeslutninger. Du kan finde flere oplysninger om almindelige implementeringsmodeller og vigtige overvejelser i oplysningerne om implementeringsmodeller for samarbejde, der er tilgængelige i Collaboration SRND.
En anden vigtig implementeringsovervejelser, når du overgår til, er tilgængelighed. har forskellige funktioner, abonnementer og enheder, der er tilgængelige afhængigt af, hvor installationen er placeret. Du kan finde flere oplysninger om geografisk tilgængelighed under Hvor er Webex tilgængelig? .
Endelig er det vigtigt at forstå, hvilken indvirkning overgangen til vil have på andre samarbejdstjenester. Baseret på formålet med dette dokument er den generelle antagelse, at hvis eksisterende samarbejdstjenester uden for opkaldsarbejdsbyr den skal opretholdes, forventes overgang til fase 1-hybrid-implementeringen, der er nævnt ovenfor. Eksempler på samarbejdstjenester, der kan kræve hybrid udrulning, omfatter det lokale kontaktcenter, der endnu ikke er overført til Webex-kontaktcenter, og tætte integrationer i systemer som personsøgningssystemer og fakturering. Du kan finde flere oplysninger om overgangen til yderligere samarbejdsarbejdsbelastninger og -tjenester under Samarbejdsovergange.
Beholdning af eksisterende enheder/klienter
Før overgangen påbegyndes, er det vigtigt at opbevare dine eksisterende hardware- og softwareslutpunkter. Hvis du har en komplet liste over enhedstyper/modeller, hardwareversioner, softclient-OS-typer og mængder, sikrer du, at du i tilstrækkelig grad kan planlægge overgangen til enh ederne og mindske virkningen for de enheder, der ikke kan migreres til cloud-opkald. Opgørelsen skal bruges til at bestemme de enheder, der skal overgås, og de enheder, der skal udskiftes inden overgangen.
Skrivebordstelefoner
Til skrivebordstelefoner med lyd og video understøttes kun skrivebordstelefoner i 6800, 7800, 8800 og 9800-serien. Dette er en undergruppe af de Cisco IP-telefoner, der understøttes med. Der er nogle modeller og versioner af 6800, 7800 og 8800 telefoner, der ikke kan bruges med. Du kan finde flere oplysninger om, hvilke modeller og hardwareversioner der understøttes, under Under støttede enheder til Webex Calling.
Cisco 6800-seriens IP-telefoner kan ikke opgraderes fra Enterprise-firmware til Multiplatform (MPP) firmware, hvilket er påkrævet for. Derfor skal alle 6800-telefoner, der er registreret til kørende virksomhedsfirmware, udskiftes med en 6800 MPP-model eller med en anden understøttet telefonmodel.
Cisco 7800- og 8800-seriens IP-telefoner skal opgraderes til MPP- firmwaren (Multiplatform Phone) før overgang og registrering af dem til. For at finde ud af, hvilke 7800- og 8800-modeller og hardwareversioner, der understøtter MPP-firmwaren, skal du se Konvertere IP-telefoner i Cisco 7800- og 8800-serien mellem Enterprise - og MPP-firmware.
8845, 8865 og 8865NR har nået slutningen af salget og anbefales ikke at migrere til.
Ældre versioner af 8800-seriens telefoner (8811, 8841, 8851, 8851NR, 8861) anbefales ikke at bruge sammen med. Webex Calling Telefoner med hardwareversioner VID 14 eller tidligere registreres med, men kan opleve nogle ydelsesproblemer på grund af hardwaren.
9800-seriens bordtelefoner kører PhoneOS, som understøtter både og registrering. Derfor kan disse telefoner overgås til uden en firmwareopgradering.
Alle andre IP-telefoner skal udskiftes med en 6800, 7800, 8800 eller 9800-serie telefoner, der understøttes af. Webex Calling Du kan finde flere oplysninger om understøttede IP- og skrivebordstelefoner med i artiklen under Under støttede enheder til Webex Calling.
Videoslutpunkter
Personlige og rumvideoslutpunkter, herunder Cisco Board-serien, Room-serien og Desk- serien, kan oprindeligt SIP-registreres til. Alle disse slutpunkter, der skal foretage lyd- og/eller PSTN-opkald, kræver en opkaldslicens:
-
Delte enheder i konferencelokaler, mødelokaler osv. kræver enten en Professional Workspace- eller Workspace-licens.
-
En slutbrugers personlige enhed kræver en professionel licens eller standardlicens.
Bestem, hvor mange videoslutpunkter der er registreret til og bruges til at foretage lydopkald. Det er muligt, at nogle af videoslutpunkterne kun kan bruges til at deltage i møder eller foretage SIP-videoopkald. I begge tilfælde skal slutpunkterne stadig migreres til, før serverne tages ud af drift, men dette vil hjælpe med at bestemme, hvor mange af dem der har brug for en licens for at fortsætte med at foretage telefonopkald.
-
Når videoenheder flyttes fra registrering til, ændres URI'en for disse slutpunkter, da de nu er registreret i skyen.
-
Telefonmodeller 8845, 8865 og 8875 er personlige video telefoner, der understøttes med.
Bløde klienter
Det er den eneste bløde klient, der understøttes af, i modsætning til Unified CM hvilken understøtter både Webex-appen og Jabber, og er den nye standard bløde klient for slutbrugere.
Afhængigt af den eller de implementeringstilstande, der er implementeret for Jabber (IM-kun, kun telefon og/eller fuld UC-tilstand), skal du muligvis også overveje overgangen af arbejdsbelastningerne til Messaging og/eller Møder fra Jabber til. Den kan implementeres i telefon tilstand, hvis den vil blive brugt som en klient, der kun ringer, eller den kan implementeres som fuld, Webex Suite hvis andre arbejdsbelastninger, f.eks. Webex Messagingog/ellerWebex Meetings, bliver overgået til appen med opkald.
Det forbedrer slutbrugerens oplevelse ved at levere AI-funktioner som lyd/ video intelligens, opkaldstransskription og andre. Du kan finde flere oplysninger på https://www.webex.com/all-new-webex.
Før du flytter brugere til, skal du overføre deres Jabber-klienter til. Du har to muligheder for at fuldføre denne overgang.
-
Før du overfører dem til
-
Når du overfører dem til.
For at lette den indledende overgang til, anbefales det at bruge mulighed 1 og flytte brugere til med opkald først. Dette giver brugerne tid til at gøre sig bekendt med den nye applikation, mens de stadig bruger den eksisterende lokale opkaldsplatform. Når du er klar til at flytte brugere til, konfigurerer du dem til at registrere sig på skyopkaldsplatformen.
For mere information om disse to muligheder, se Migrationsrejse - et eller to trin? .
For en komplet liste over de understøttede enheder til, se Under støttede enheder til Webex Calling.
Bekræft enhedens berettigelse
Som nævnt tidligere understøtter det en undergruppe af Cisco IP-telefoner og kræver en anden firmwaretype til telefonerne i 7800 og 8800-serien. Unified CMtelefoner kører Enterprise-firmwaren, mens telefoner kører multiplatform Phone (MPP) firmware. Det anbefales at kontrollere, hvilke registrerede telefoner der er kvalificerede til at opgradere til MPP-firmwaren i forberedelsesfasen. Dette giver dig tid til at erstatte ikke-kvalificerede telefoner med en af de understøttede telefonmodeller eller til at identificere en alternativ plan, som at flytte en bruger kun til Webex-appen.
For at hjælpe med at bestemme telefonernes berettigelse har Control Hub et indbygget værktøj kaldet Migrere din telefon til Webex Calling. Når du bruger dette værktøj til at kontrollere enhedens berettigelse, skal du vælge indstillingen Overførsel Generer kun enhedslicens.
Denne mulighed giver dig mulighed for at uploade en CSV-fil, der indeholder telefonerne, så du kan kontrollere, om hver telefon er berettiget. Ved at vælge denne migreringsindstilling føjer den ikke telefonerne til, da du stadig er i forberedelsesfasen og ikke er klar til at gøre dette endnu. Du kan finde flere oplysninger under Overfør din telefon til Webex Calling.
Det er muligt, at nogle af telefonerne kan komme tilbage med en ukendt berettigelse. Dette skyldes typisk, at det ikke er muligt at validere nogle oplysninger om telefonen i back-end-systemet. For alle telefoner, der har status U kendt, har du to muligheder for at kontrollere, om de er kvalificerede til at opgradere til MPP-firmwaren.
-
Kontroller manuelt hver telefon, og kontroller model- og hardwareversionen (PID VID)
7800/8800 telefonetiket med model- og hardwareversionsoplysninger -
Brug Cisco IP-telefonberedskabsværktøjet
Download værktøjet fra https://github.com/joemar2/mpp_readiness_check.
Dette værktøj er ikke et officielt Cisco-værktøj, og det understøttes heller ikke TAC. Det har den bedste indsatsunder støttelse, men er gratis at bruge.
Dette værktøj skal køres på en computer, der er i det lokale miljø og kan få adgang til serverne og IP-telefonerne. Det har en mulighed for at aktivere webadgang på IP-telefonerne, hvilket anbefales og er nødvendigt for at få de bedste resultater. Derfor bør det bruges i fritiden for at undgå forstyrrelser for slutbrugerne. Udgangen fra værktøjet indeholder en rapport, der viser, hvilke af telefonerne i 7800- og 8800-serien, der er berettiget til at opgradere til MPP-firmwaren. Fordi den direkte får adgang til telefonen, kan den bekræfte de ukendte enheder, der blev rapporteret fra Control Hub-værktøjet.
Rapport om Cisco IP-telefonberedskabsværktøj
Brugere
Et af de vigtigste forberedelsestrin for at sikre, at du har en vellykket overførsel, er korrekt brugerklargøring. Du skal planlægge korrekt for alle brugere, selvom du foretager en trinvis overførsel . Brugere skal være klargjort til et af følgende:
-
Implementering af med opkald
-
Implementering af med
-
Konfiguration af tjenester til en bruger
-
For at gøre brugere søgbare i biblioteket (klik for at ringe, brugerkontaktoplysninger, telefonkatalogsøgning).
Det anbefales, at du klargør alle brugere før eller ved projektets start. Dette inkluderer brugere, der stadig bruger deres op Unified CM kaldsplatform, der er uafhængig af deres opkaldsenhed (IP-telefon, Jabber,). Efterhånden som brugerne bliver migreret til (og/eller), opdaterer du deres licenser for at aktivere de tjenester, de har brug for. Ved at klarlægge alle brugere med virksomhedsopkald, før overgangen påbegyndes, giver den en bruger, der har overgået til eller, mulighed for at søge i mappen efter en virksomhedsopkaldende bruger, der stadig er på Jabber og/eller slået til. Dette sikrer, at overførte brugere kan finde enhver anden brugers kontaktoplysninger og foretage et opkald til dem ved hjælp af katalogopslaget.
Figur katalogsøgningen viser et eksempel på en bruger, der søger efter en anden bruger. Søgeresultaterne viser brugerens kontaktoplysninger og kan være for en bruger, der stadig er på Jabber, og eller for en bruger, der har overgået til og/eller.
Bestem derefter, hvilke af de eksisterende lokale opkaldsbrugere der skal overføres til. Hvis alle eller et stort antal brugere vil blive overgået, anbefales det at flytte brugere i grupper for at sikre, at projektteam, it-personale og supportpersonale er i stand til at håndtere overgangen og eventuelle problemer, der måtte opstå. Du bør også afsætte lidt tid til at give indledende information og træningssessioner for at forberede brugerne på denne overgang. Gruppering af bruger overgange kan udføres baseret på en række kriterier, herunder den placering eller det websted, brugerne er tildelt, brugerafdelinger eller endda brugertyper (vidensarbejdere, ledere, mobile arbejdere osv.).
Hvis brugerne i implementeringen f.eks. er opdelt på tre hovedsteder, New York (NYC), San Francisco (SFC) og Research Triangle Park (RTP), kan en brugerovergangsplan se ud som den plan, der er beskrevet i Brugerovergangsplan for lokalitetstabel.
| Brugerwebsted/placering | Information og træningssessioner før overgangen | Overgangsperiode | Støtte efter overgangen |
|---|---|---|---|
| NYC (1.525 brugere) | Ugen den 1. april | 15. april — 27. april | Ugen 29. april |
| SFO (1.600 brugere) | Ugen den 6. maj | Maj 20 - Maj 31 | Ugen den 3. juni |
| RTP (1.275 brugere) | Ugen den 3. juni | 17. juni — 28. juni | Ugen den 1. juli |
En anden vigtig faktor er at overføre brugere sammen, der har afhængigheder mellem hinanden . Dette kan omfatte, men er ikke begrænset til, følgende:
-
BLF-overvågning
-
Samme jagtpilot/gruppe
-
Del linjer
-
Del af samme gruppe for afhentning af opkald
-
Brug af de samme call-park-numre
-
Intercom
-
Admin/Exec.
Du kan gennemgå konfigurationen (GUI eller eksport) eller bruge værktøjet Migration Insights til at identificere de grupper af brugere med disse afhængigheder.
PSTN-forbindelse
kan få adgang til PSTN på tre måder: Cisco-opkaldsplaner, Cloud connect for (tidligere Cloud Connected PSTN) og lokal PSTN (lokal gateway). En enkelt placering som defineret inden for kan dog kun tildeles til en enkelt PSTN-indstilling.
Lokalt PSTN med en lokal gateway (LGW) er en væsentlig del af overgangsstrategien. Det giver forbindelse mellem den lokale implementering og/eller PSTN og platformen. understøtter både Cisco og certificerede tredjepartssessionsgrænsecontrollere (SBC), der kan bruges som lokal gateway. For den seneste liste over understøttede SBC'er, se Liste over understøttede SB C'er.
understøtter op til 250 samtidige opkald fra en enkelt lokal gateway, der er registreringsbaseret, og mere end 250 samtidige opkald fra en enkelt lokal gateway, der er certifikatbaseret. Certifikatbaserede lokale gateways kan understøtte op til 6500 samtidige opkald, men dette er baseret på den type forbindelse, den lokale gateway skal have (Over-the-Top vs interconnect peering) og den SBC-model, som den lokale gateway er implementeret på. Disse grænser er i det væsentlige standardtællingsgrænsen for både lokale gateway-baserede PSTN-opkald og opkald mellem websteder mellem og slutpunkter. Du kan finde flere oplysninger under Kom godt i gang med lokal gateway.
Alle opkald, der overskrider denne grænse, afvises med en 403 forbudt. Vis opkald aktiv stemmek ommando kan køres på den lokale gateway når som helst for at bestemme det samlede antal aktive opkald.
Dårlige netværksforhold mellem en lokal gateway og adgangsSBC kan begrænse signalforbindelsens ydeevne, hvilket fører til en endnu lavere grænse for samtidige opkald. Envejs ventetid mellem den lokale gateway og datacentret bør ikke overstige 100 ms, og jitter bør være mindre end 10 ms, mens pakketab er mindre end 0,5%.
Funktioner og funktionsbrug
Når du vurderer det aktuelle miljø, er det vigtigt at identificere og gennemgå, hvilke funktioner der er konfigureret. Derudover er det vigtigt at forstå brugen af funktionerne , så du kan (igen) definere dine forretningsmæssige og tekniske krav til din implementering.
For at bestemme, hvilke funktioner der er konfigureret, skal du analysere konfigurationen. Dette er alle statiske data, der indstilles, når en funktion eller indstilling er konfigureret på systemet. Følgende muligheder kan bruges til at fuldføre denne analyse:
-
Gennemgå konfiguration i admin GUI
-
konfigurationseksport - masseeksport eller AXL
-
værktøj til migrationsindsigt (anbefales)
-
Cisco tredjeparts partnerværktøjer (Anbefalet).
For at analysere funktionsudnyttelse effektivt er det vigtigt at undersøge dynamiske systemdata såsom udnyttelse, registreringer og opkald saktivitet. Forskellige analyseværktøjer og dashboards giver indsigt i disse målinger, hvilket muliggør en omfattende forståelse af systemets ydeevne og kapacitet, hvilket understøtter informeret beslutningstagning under migrering og optimering. Følgende muligheder kan bruges til at fuldføre denne type analyse:
-
Gennemgang af rå CDR-poster
-
Gennemgang af Unified CM RTMT-data
-
Migration Insights værktøj ved hjælp af CDR-data
-
Gennemgang af Cloud-Connected UC-analyse i
-
Opkaldsvolumen
-
Registrerede slutpunkter
-
(CAC) placeringer
-
Udnyttelse af bagagerummet.
-
-
Cisco tredjeparts partnerværktøjer.
Cisco anbefaler, at du starter med værktøjet Webex Control Hub Migration Insights til denne analyse. Du importerer din eksport.TAR-fil og Unified CM CDR-filer (valgfrit, men påkrævet til analyse af funktionsud nyttelse) til værktøjet. Værktøjet genererer følgende CSV-baserede rapporter , der kan bruges til at starte analysen:
| Rapportnavn Rapportbeskrivelse |
|---|
| ImportedDataBulk.csv
Alle brugere og enheder fra Unified CM data |
| DeviceEligibility.csv
Identificerer enheder, der er kvalificerede til at migrere til Webex Calling (IP-telefoner, Room OS- enheder, ATA'er og tredjepart) |
| DevicePoolNumbers.txt Liste over alle numre i en bestemt enhedspul je |
| HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv Detaljer om enheder og brugere, der skal migreres sammen baseret på delte linjer, jagt pilot, opkaldskø, opkaldspark og opkaldsafhentningsgruppe |
| HuntGroupMigrationInsight.csv Detaljerede oplysninger om tildelte jag tlinjer, linjegrupper og tilknyttede agenter |
| SharedlineGroupMigrationReport.csv Oversigt over, hvordan telefonnumre (katalognumre) deles mellem brugere |
| Rapportnavn Rapportbeskrivelse |
|---|
| FeatureUsageBasedDeviceEligibilityReport.csv Oplysninger om berettigelse til enheds migration baseret på funktionsbrug |
| FeatureUsageWithLastUsageDateReport.csv Brugstal for det antal gange jagtpilot (er) og opkaldskø (er) er blevet kaldt sammen med den sidste brugs dato |
| UserWorkspaceLastUsage.csv Sidste brugsdato for brugere og arbejdsområder for både bløde klienter og hardtelefoner |
| DIDUsageReport.csv DID-brug for både tildelte og ikke-tildelte DID'er |
Du kan finde flere oplysninger om rapporterne Migration Insights under Overfør sel sindsigt.
Hvis du har brug for flere oplysninger om funktionerne og brugen efter at have gennemgået oplysningerne i Migration Insights-rapporterne, anbefaler Cisco at overveje et af Ciscos tredjepartsmigreringsværktøjer til partnere og/eller at gennemgå konfigurationerne i GUI eller i konfigurationseksportdataene.
Cisco-integrationer: Unity-forbindelse UCCX UCCE
Voicemail er en integreret del af tilbuddet og indbygget i løsningen. kan ikke integreres med en lokalbaseret voicemail-løsning som Unity Connection eller Unity Connection Express. Yderligere, der er ingen indbygget måde at migrere eksisterende Unity-forbindelses voicemail-beskeder eller hilsener til den oprindelige voicemail-tjeneste, der er tilgængelig med. Nogle af Ciscos tredjepartspartners migreringsværktøjer har muligheder for at migrere nogle af disse data. Du kan finde flere oplysninger om telefonsvarer til under Konfigurere og administrere indstillinger for telefonsvarer for en bruger. Webex Calling
understøtter også delte telefonsvarer og faxpostkasser. Du kan finde flere oplysninger i Administrer en delt telefonsvarer og indgående fax boks for. Webex Calling
har en indbygget Auto Attendant-funktion, der er inkluderet som en del af kerneplatformen. Denne funktion giver mulighed for overgang af din Unity Connections opkaldshåndterere og automatisk ledsager funktionalitet . Værktøjet Control Hub, Migrere funktioner fraUnified CM, understøtter migrering af Unity-forbindelseskonfigurationer til automatiske ledsagere. Du kan finde flere oplysninger om brug af dette værktøj under Overførsel af enheder og funktioner fra Unified CM tilWebex Calling.
Opkaldsoptagelse
inkluderer to muligheder for opkaldsoptagelse uden ekstra omkostninger.
-
Webex opkaldsoptagelse
-
Dubber Go-optagelse (partnertilbud) - en integration mellem og dubber, hvor alle optagede medier opbevares sikkert i skyen.
Inkluderet optagelses indstillingstabel fremhæver nogle nøglefunktioner i de to opkaldsoptagelsesmuligheder, der er tilgængelige uden ekstra omkostninger.
| Webex | Double Go |
|---|---|
| Tilgængelig for alle brugere | Tilgængelig for alle brugere |
| Ubegrænsede optagelser | Ubegrænsede optagelser |
| 1 års opbevaringsperiode* | 30-dages opbevaringsperiode |
| 100 GB lagerplads pr. Org | - |
| Compliance-medarbejdere kan få adgang til og administrere opkaldsoptagelser | - |
| API'er til styring af optagelser | - |
Administratorer kan konfigurere og administrere brugernes adgang til deres opkaldsoptagelser
|
Kun brugere kan få adgang til og administrere deres optagelser
|
Hvis din organisation kræver yderligere optagefunktioner som op tagelse af overholdelsesopkald, længere opbevaringsperioder, mere lagerplads, AI-analyse og/eller administratoradgang, findes der betalte tilbud eller tilføjelser fra både Cisco og tredjeparts optagelsesudbydere. Du kan finde flere oplysninger om optagelsesudbydere, konfigurationer og tilføjelsespartnertjenester under Administrer opkaldsoptagelse for Webex Calling.
Tredjepartsintegrationer
understøtter en række tredjepartsintegr ationer, herunder men ikke begrænset til SBC'er til lokale gateways, IP-telefoner, intercom-telefoner, højttaler/personsøgere, ATA'er osv. Ud over disse tredjepart sen heder Webex Calling understøtter de forskellige tredjepart sl øsninger til kundesupport, analyse, optagelse, fakturering osv. Du kan finde flere oplysninger om tredje partsløsninger under Webex App Hub.
Planlæg
Projektplan på højt niveau
Når man udvikler en projektplan på højt niveau for migrering fra til, er det vigtigt at etablere klare faser og milepæle, der stemmer overens med både forretningsmæssige mål og tekniske krav. Planen bør begynde med en omfattende vurderings fase, herunder indsamling af detaljerede tekniske og forretningsmæssige krav, samt identifikation af interessenter og definition af succeskriterier. Nøgleovervejelser inkluderer ressource allokering, tidslinjeestimering, risikostyring og kommunikationsstrategier for at sikre, at alle parter er informeret og engageret under hele migrationen. Derudover bør planen omfatte validering skontrolpunkter såsom pilottest og trinvise udrulninger for at minimere forstyrrelser og give mulighed for justeringer baseret på feedback.
Eksempler på elementer, der skal medtages i projektplanen, er:
-
Definere omfanget af migrering (f.eks. hvilke brugere, enheder og funktioner der skal overgå)
-
Planlægning af træningssessioner for slutbrugere og supportteams
-
koordinering af vurderinger af netværksberedskab og
-
Planlægning af cutover-aktiviteter med fallback-muligheder. Det er også vigtigt at integrere overholdelses- og sikkerhedsvurderinger samt support- og optimerings faser efter migrering.
Ved at strukturere projektplanen med disse overvejelser kan organisationer bedre styre kompleksitet, reducere risici og opnå en glattere overgang til.
Migrationsrejse - et eller to trin?
kræver, at brugerne bruger den til deres opkaldende soft klient. Derfor, hvis nogen brugere stadig bruger, har du to muligheder for, hvornår du kan flytte dem til. Du kan enten foretage en brugeroverførsel i et enkelt trin eller en brugeroverførsel i to trin.
Valgmulighed 1: Enkelttrinsbrugermigrering
I et enkelt trin overgår brugerne fra til det, samtidig med at de overgår fra Unified CM til. Denne mulighed er typisk for kunder med et lille antal brugere at migrere og kan administrere at flytte både brugerens bløde klient og opkaldstjeneste til på samme tid. Figuren Brugerens opkaldstjeneste, softklient og telefon migrerer til på samme tid nedenfor fremhæver denne type migration. Med denne mulighed vil en bruger have følgende gennemført på samme tid:
-
Opkaldstjenester flyttet fra til
-
Telefonnumre og udvidelser flyttet fra til
-
Soft client overgik fra Jabber til - vil registrere sig til
-
Telefonregistrering flyttet fra til.
Dette kan stadig være en trinvis overførsel, hvor grupper af brugere flyttes på forskellige tidspunkter, men når hver bruger flyttes, sker alle disse på samme tid.
Mulighed 2: Migrering af brugere i to trin
Den anden tilgang er en totrinsmigration. I trin 1 skiftes brugerne fra til, men forbliver på opkaldstjenester. Derefter flyttes brugerne i trin 2 fra Unified CM til. Denne indstilling anbefales til større kunder til at administrere slutbrugerændringerne og ønsker at ad skille brugerens bløde klientændring fra ændringen af opkaldstjenesten. Følgende figur Migrere blød klient; derefter migrere opkaldstjeneste, softklient og telefon til Webex Calling nedenfor fremhæver denne type overførsel.
Trin 1
-
Soft client overgået fra til - vil registrere sig til.
Trin 2
-
Opkaldstjenester flyttet fra til.
-
Telefonnumre og udvidelser flyttet fra til.
-
registrering flyttet fra til.
-
Telefonregistrering flyttet fra til.
Dette kan stadig være en trinvis migrering, hvor grupper af brugere flyttes på forskellige tidspunkter i begge trin.
Den indstilling, du vælger, afhænger af, hvordan du vil administrere dine brugeres overgang til og. Anbefalingen er at tage det i trin (mulighed 2). Dette giver dig mulighed for at minimere slut brugerens ændringer på én gang og opdele indsatsen på tværs af forskellige dele af projektet. Men hvis du foretrækker at have brugere kun påvirket én gang, er brug af mulighed 1 også gyldig.
Når man ser på den anbefalede rejse (mulighed 1), viser overgangskortet Jabber til Webex App på højt niveau nedenfor overgangen på højt niveau for trin 1.
I dette trin overgår brugerne fra Jabber til alle deres opkaldstjenester. Opkaldsplatformen er dog stadig, Unified CM og den vil registrere sine opkaldstjenester til. Som det ses i overgangskortet Jabber til Webex App på højt niveau ændres infrastrukturen i det lokale miljø ikke, og det fungerer på samme måde, som Jabber gør. Den eneste ændring er, at der kræves en forbindelse ud til.
Du kan finde flere oplysninger om denne overgang i Vej ledning til overgangskort og implementering af Jabber til Webex under afsnittet Klient på siden Samarbejdsovergang.
Unified CMtil over Webex Calling gangskortfigur på højt niveau er over gangen på højt niveau fra til. Dette er trin 2 af den anbefalede rejse.
Hvis du beslutter dig for at bruge enkelttrinsmetoden, gælder dette også.
I dette trin overføres brugere til i grupper. På dette tidspunkt begynder brugerne at bruge til deres opkaldstjenester, opkaldsregistrering og IP-telefonregistrering.
Da brugerne bevæger sig i grupper, vil Enterprise-brugere blive delt mellem de to opkal dsplatforme under overgangen. Fase 1 i Unified CMover gang Webex Calling skortfiguren på højt niveau viser denne tilstand. I denne fase kræves planlægning for, hvordan man administrerer opkald mellem brugere på de to platforme, og hvordan PSTN-opkald vil blive dirigeret. Hver gang en gruppe brugere skiftes til, kræves der opkaldsplaner og opdateringer af opkaldsruting på og den eller de lokale gateway (er).
Når alle brugere, bløde klienter og enheder er blevet overført til (fase 2), kan al lokal UC-infrastruktur fjernes og tages ud af drift.
Udformning
Valg af region
er tilgængelig globalt og leveres fra redundante datacentre i flere regioner: USA (Dallas, Chicago), Canada (Vancouver, Toronto), Europa (Frankfurt, Amsterdam), Storbritannien (London, Manchester), Australien (Melbourne, Sydney), Japan (Tokyo, Osaka), Saudi-Arabien (Riyadh, Jeddah) og Indien (Mumbai, Chennai). Medie-POP'erne leverer medietjenester for at optimere mediernes rundturtider. Singapore-datacentret bruges for eksempel til at optimere mediernes tur -returtider for kunder i asiatiske lande, hvor rundturstiderne til enten Australien eller Japan- regionen kan være suboptimale. Datacentrene er forbundet med en multi-gigabit og fuldt redundant rygrad. Figuren globalt distribuerede datacentre viser et overblik over alle datacentre. For den seneste liste over tilgængelige datacentre, se Datacenterplaceringer for Webex Calling.
Hver kunde er klargjort på en af instanserne. Alle klargøringsoplysninger for den pågældende kunde gemmes i den pågældende instans, og SIP-signaleringen af alle slutpunkter og lokale gateways, der er klargjort for den pågældende kunde, er bundet til den forekomst, kunden er klargjort på. Fordi det er svært at ændre det oprindelige regionvalg, er det vigtigt at overveje alle relevante faktorer som en del af beslut ningsprocessen, der fører til regionudvælgelsen. For at undgå overdreven signalreturforsinkelse er det vigtigt tidligt i overgangsprocessen at beslutte, hvilken instans der skal bruges. Cisco anbefaler, at du vælger den forekomst, der giver de laveste signaleringstider for det største antal brugere inden for implementeringen.
Se Hvor er Webex tilgængelig? Se, hvor er Webex tilgængelig? .
Lokaliteter
For at forberede klargøring af placeringer skal de nødvendige oplysninger for alle overførselsmål indsamles. De oplysninger, der er nødvendige for hver placering, er opsummeret i Oplysninger, der skal indsamles for hver placering.
| Oplysning | Kommentar |
|---|---|
| Udvidelsesområde (r) | Hver placering i kan have udvidelser, der starter med forskellige cifre. Der skal spares et ciffer for
styretumstallet mellem lokalerne (f.eks. 8) og et for PSTN-
styretumcifferet (f.eks. 9). Intet udvidelsesområde kan starte med nogen af
disse to cifre. Alle udvidelsesintervaller på alle placeringer skal være af samme længde. |
| DID-område (r) | - |
| PSTN styretøj | - |
| Webstedskode | Alle webstedskoder på alle placeringer skal være unikke og have samme længde. |
| Hovednummer | Når du opretter en placering, skal to DID'er klarlægges. Et som
hovednummer (for eksempel til at blive tildelt en automatisk svartjeneste) og et til telefonsvar
erportalen. Bestem en DID til telefonsvarernummeret. |
| Voicemail nummer | |
| Antal licenser | Påkrævede licenser efter type inklusive Standard, Professional, Workspace, Ruteliste, Udgående opkaldsplan. |
| Samtidige opkald i den travle time | Summen af samtidige opkald mellem enheder og mellem enheder og den lokale gateway (PSTN og opkald til enheder). Nødvendigt for at bestemme den nødvendige båndbredde til internetadgang. |
| Land | - |
| Tidszone | - |
| Sprog | - |
| Kontakt (Navn, Telefon, E-mail) | - |
| Adresse (gadeadresse, by, stat, postnummer) | - |
| Redningstjenesternes fysiske afsendelsessted for slutpunkter | Enhedens afsendelsessted, der bruges til nødopkald, omfatter generelt følgende: bygningsadresse, bygningsadresse + etagenummer, bygningsadresse + suite nummer eller bygningsadresse + etagenummer + kontor/kubiknummer. |
| Entydig fysisk netværksplacering pr. enhed for alarmtjenester | Fysisk netværksplacering til nødopkald omfatter generelt følgende: switch/switchport til kabelforbundne enheder, BSSID'er (Wireless Access Point) Basic Service Set Identifiers (BSSID'er) for trådløst tilsluttede enheder og/eller lokale IP-undernet (er) til slutpunktsenheder. |
PSTN
Når kunderne designer en udrulning, har kunderne tre primære PSTN-tilslutningsmuligheder: Cisco C alling-planer (en cloud-leveret PSTN-tjeneste administreret af Cisco), Cloud Connec ted PSTN-udbydere (CCPP, hvor udbydere leverer PSTN-tjenester via skyen) og PSTN i det lokale miljø (hvor lokale gateways forbinder virksomhedsnetværket med PSTN). Med introduktionen af PSTN-trunking til hybrid-implementeringer (for mere information, se PSTN-trunking til hybrid-implementeringer ved PSTN-trunking) får Webex Calling organisationer yderligere fleksibilitet i deres migreringstilgang. Denne funktion gør det muligt for kunder at flytte deres PSTN til CCPP i starten af overgangs rejsen og begynde overgangen til cloud PSTN for brugere, mens de udnytter CCPP til at opretholde PSTN-service for brugere, der forbliver på Cisco under en trinvis migration.
Denne hybride tilgang giver organisationer mulighed for først at flytte udvalgte brugergrupper til skyen uden straks at revidere hele deres telefonimiljø. Det introducerer dog yderligere kompleksitet og risiko, især omkring tilpasning af eksisterende opkaldsroutingslogik til at understøtte den nye arkitektur. Interoperabilitet med ældre applikationer, såsom faxservere, kontaktcentre eller personsøgnings systemer, kræver også nøje overvejelse. De vigtigste tekniske udfordringer kan omfatte sikring af problemfri end-to-end-codec-forhandling og DTMF-signalering (Dual-Tone Multi-Frequency) på tværs af det blandede miljø samt validering af kompatibilitet med specialiserede telefonifunktioner. Korrekt planlægning og test er afgørende for at minimere forstyrrelser og opretholde pålidelige taletjenester gennem hele migrationsprocessen. Derudover er kommercielle overvejelser vigtige, da hybrid trunking kræver en brugslic ens, der er baseret på antallet af samtidige opkald mellem det lokale miljø og Cloud Connected PSTN Provider (CCPP).
Alternativt kan organisationer vælge at bevare deres lokale PSTN-forbindelse gennem hele overgangsfasen. I dette scenarie kan migrering til CCPP udføres på to måder: som en enkelt, koordineret cutover for alle brugere og placeringer, når migreringen er afsluttet, eller trinvist, hvor PSTN-migrering finder sted pr. placering, når brugerne flyttes til. Denne tilgang kan hjælpe med at strømline sameksistens og opretholde kontinuitet for ældre integrationer, men det introducerer flere operationelle kompleksiteter. Blandt disse er udfordringer relateret til nummerportering, såsom behovet for præcis koordinering af nummerportordrer, potentielle forsinkelser, og udbyderpålagte begrænsninger som et loft på antallet af samtidige portanmodninger eller begrænsninger for portering af delsæt af store antalblokke. Organisationer skal omhyggeligt planlægge deres PSTN-overgangsstrategi og tage højde for disse logistiske overvejelser for at undgå serviceafbrydelser og sikre en problemfri migrationsoplevelse.
Figuren Overførsel til CCCP i starten vs. opbevaring af PSTN i det lokale miljø viser de to PSTN-overførselsin dstillinger, der er beskrevet ovenfor. Illustrationen til venstre viser scenariet, hvor alle brugere og programmer i det lokale miljø bruger Cloud Connec ted PSTN-tjenester via en on-premises trunk og en lokal gateway, der forbinder det lokale miljø med, mens illustrationen til højre viser scenariet, hvor det eksisterende lokale PSTN forbliver på plads, og brugere anvender PSTN i det lokale miljø via den lokale gateway-forbindelse mellem det Webex Calling lokale miljø og. Under overgangen kan placeringer skiftes til ved hjælp af Cloud Connected PSTN.
I begge scenarier bruger opkald mellem det lokale miljø og brugeren den lokale gateway-forbindelse. Forbindelsen mellem lokalt og skal designes og dimensioneres i overensstemmelse hermed baseret på det forventede antal samtidige opkald og den krævede redundans.
Opkaldsplan
For at opnå problemfri interoperabilitet mellem og i migrationsperioden skal der udvikl es og implementeres en omfattende opkaldsplanarkitektur på tværs af begge platforme. Dette opkaldsplandesign med to platforme sikrer ensartet opkal dsrouting, nummeroversættelse og funktionsgennemsigtighed, hvilket gør det muligt for brugere på begge systemer at kommunikere uden tjenesteforringelse eller forstyrrelser i brugeroplevelsen i hele sameksistensfasen.
Opkaldsplan i det lokale miljø
Under overgangen for at muliggøre sameksistens mellem enheder, der er registreret på Unified CM og på virksomheden, skal opkaldsplanen ændres, så som minimum følgende krav kan opfyldes:
-
+E.164 opkald fra til
-
Udvidelsesopkald fra til (internt på stedet, men også mellem lokaliteter, hvis udvidelsesområderne er unikke)
-
Forkortet opkald mellem websteder fra til
-
Tvunget opkald på nettet fra til
-
Tilbagekald fra mappen for ubesvarede opkald til destinationer på
-
PSTN-opkald fra til PSTN, hvis der under overgangen bruges det lokale PSTN til
-
PSTN-opkald fra til hvis under overgangen PSTN-trunking til hybridinstallationer bruges til at give PSTN-adgang til brugere i det lokale miljø via Cloud Connect til
-
Tvunget på nettet fra til
-
Udvidelsesopkald fra til (mellem websteder).
Hvis nogen af ovenstående ikke er understøttede opkaldsvaner før overgangen, for eksempel eksisterer der ingen forkortet opkaldsvane mellem websteder, behøver de ikke nødvendigvis at indføres under overgangen.
Figur Opkalds plan for bedste fremgangsmåder viser den bedste fremgangsmåde for opkaldsplan som beskrevet i Preferred Architecture for Cisco Collaboration 12.x Enterprise On-Premises Imployments, CVD. Nøglekarakteristika ved denne tilgang inkluderer:
-
Enkelt partition til+E.164 katalognumre
-
Kernerutning baseret på+E.164 rutemønstre
-
Normalisering af alle opkaldsvaner til+E.164 ved hjælp af oversættelsesmønstre
-
Brug af oversættelsesmønster, der kalder arv af søgerum (mulighed Brug ophavsmandens opkal dssøgerum ind stillet på oversættelsesmønstre).
For eksempel vil PSTN-opkald (9+1+10D) fra en enhed i SJC, der er forsynet med sø geområde for linjeopkald SJCinternational, først blive matchet af oversættelsesmønsteret 9.1 [2-9] XX [2-9] XXXXXX, som normaliserer det opkaldte partnummer til +E.164. Det sekundære opslag bruger derefter det samme opkaldssøgningsrum SJCinternational igen (kalder søgerumsarv), og strengen +E.164-cifrede vil enten blive matchet af et +E.164-mappenummer i DN-partitionen eller af et af PST N- rutemønstrene i partitionen USPSTNnational eller SJCPSTNLocal. Forkortede intra-site- og inter-site-opkaldsvaner implementeres af oversættelserne i ES N- og SJCTOE164-partitionen. Mens ESN- partitionen er en global partition (tilgængelig for telefoner på alle placeringer), er SJCTOE16 4-partitionen kun tilgængelig for brugere på stedet SJC. Dette forudsætter overlappende udvidelsesintervaller.
Det første skridt til at aktivere opkald fra til er at sikre, at +E.164-destinationer bliver dirigeret i overensstemmelse hermed. Dette kan opnås ved at tilføje en partition til opkaldsplanen, tilføje+E.164 rutemønstre for alle destinationer til den partition og til sidst tilføje partitionen til alle opkaldende søgerum, der repræsenterer klasser af tjenester, som skal være i stand til at nå. Oprettelse af en dedikeret partition er påkrævet for at muliggøre oprettelse af en differentieret serviceklasse til opkald, der stammer fra. For at undgå opkaldssløjfer bør det indgående opkaldssøgningsrum på bagagerummet fra den lokale gateway ikke have adgang til partitionen.
Som vist i figur +E.164 routing tilWebex Calling, for at muliggøre routing fra til for en placering med+E.164 DID-rækkevidde +1 221 555 2XXX og webstedskode 121, skal der tilføjes et presserende rutem ønster, der matcher dette+E.164-område, til partitionen.
Hvis der ikke kræves et stedspecifikt valg af lokal gateway, kan der i stedet for at bruge en ruteliste med en lokal rutegruppe som destination for rutemønstre, der peger på en enkelt rutegruppe, klarlægges med den lokale gateway som det eneste medlem, og derefter peger rutemønstrene på en enkelt ruteliste med denne ene rutegruppe som eneste post.
For at aktivere forkortet opkald mellem websteder til webstedet tilføjes det krævede rutemønster 8121.2XXX til partitionen. For websteder, der skal overføres til et opkaldsnormaliseringsmønster 8121.2XXX, der normaliserer ESN-opkald til +E. 164, findes muligvis allerede i ESN-partitionen. I så fald synes 8121.2XXX at være overflødig, men så snart alle DN'er på den respektive placering er blevet migreret over til 8121.2XXX-opkaldsnormaliseringsnormaliseringsmønsteret kan fjernes, og derefter muliggør rutemønsteret 8121.2XXX ESN-opkald, selv for brugere, der kun er udvidelsesbrugere i det pågældende område.
Med disse opkaldsplanændringer kan opkald til lokationen foretages ikke kun ved at ringe forkortet inter-site og +E.164. Desuden er internationale og nationale PSTN-opkald mulige, fordi disse opkaldsvaner først normaliseres til +E.164 gennem de allerede eksisterende oversættelsesmønstre for opkaldsnormalisering og derefter dirigeres til ved at matche +E.164-rutemønsteret i partitionen.
+E.164-rutemønstermatchningen på placeringens DID-område kan klarlægges, mens alle DID'er stadig er aktiveret. Den bedste matchende algoritme til matchende mønstre sikrer, at når der ringes op til et nummer, der er hostet på, er +E.164-katalognummeret, der er klargjort på, bedre match end rutemønsteret +E.164 med jokertegn, der peger på, så opkaldene udvides til en linje på og ikke sendes til.
opkaldsplan
Hver bruger er forsynet med en udvidelse og/eller et+E.164-telefonnummer. Udvidelseslængden er en fast global indstilling: alle udvidelser i en installation har samme længde. Udvidelsesopkald kan bruges mellem brugere både inden for et sted og mellem lokationer. Forkortet udvidel sesopkald mellem websteder (sidstnævnte tilfælde) fungerer kun, hvis den opkaldte udvidelse er unik.
Hvis forkortet opkald mellem websteder mellem lokationer er et krav, men der er overlapninger mellem udvidelser, der er tildelt forskellige placeringer, skal der oprettes en virksomhedsspecifik nummereringsplan ved at præfiksere udvidelserne med en adgangskode, en webstedskode. Du kan finde flere oplysninger under Fore trukken arkitektur for Cisco Collaboration 15 On-Preparate Imployments, Oversigt over design på Ciscos foretrukne arkitekturer for samarbejde.
Udvidelseslængden, opkaldsfunktionsmåden mellem lokaliseringsudvidelserne, præfikslængden for opkald mellem lokaliteter og styretumcifferet i routingpræfikset for opkald mellem lokaliteter er konfigureret i indstillingerne for opkaldstjenesten i:
-
Placeringsrutepræfikslæng de: Præfikslængde inklusive styretummeret. Kræ ves kun, hvis der skal etableres en virksomhedsnummerplan som alternativ forkortet virksomhedsopkaldsvane mellem lokaliteter.
-
Styretøj i routingpræfiks: Styretumstal for forkortet opkal dsvane mellem virksomheder. Overlapninger med første ciffer på ethvert sted og udgående opkaldscifre bør undgås. Kræ ves kun, hvis der skal etableres en virksomhedsnummerplan som alternativ forkortet virksomhedsopkaldsvane mellem lokaliteter.
-
Intern forlængelseslængde: Standard længde af forlængelser. Kan være en hvilken som helst værdi mellem to og ti.
Når der kræves opkald eller opkald ved hjælp af virksomhedssignifikante numre (styrekode, webstedskode, udvidelse) fra en opkaldskontrol i det lokale miljø til, og opkaldskontrollen i det lokale miljø sender en udvidelse som opkalds-id, skal du sørge for også at angive parameteren Maksimal ukendt forlængelseslængde i afsnittet Opkaldsdirigering mellem og lokaler for at sikre, at opstrømsopkald fra opkaldskon trollen i det lokale miljø kan klassificeres korrekt som opkald i det lokale miljø. -
Tillad opkald til udvidelsesopkald mellem lokationer: Ski ft for at aktivere/deaktivere opkald til udvidelsesopkald mellem lokationer . Denne indstilling bør kun aktiveres, hvis alle udvidelser i organisationen er unikke. Hvis indstillingen er deaktiveret, skal der ringes til virksomhedssignifikante numre (styrekode, webstedskode, filtypenavn) eller telefonnumre mellem lokationer.
De første tre parametre bruges hovedsageligt til at opbygge en opkaldsplan for telefoner for at minimere intercifrede timeouts, når du bruger off-hook-opkald. Afvigelser fra disse globale indstillinger er stadig mulige (Eksempel - udvidelser med en anden længde kan etableres), men der vises en advarselsmeddelelse i Control Hub, og opkald fra telefoner kræver muligvis blo kering af opkald for at undgå konflikter inden for den forudindlæste opkaldsplan.
Tabellen Enterprise nummereringseksem pel viser et eksempel på tre placeringer, hvor ud videlsesområderne for to placeringer, NYC og RTP, er identiske. Oprettelse af et virksom hedsnummereringsskema med styringsciffer 8 mellem websteder, efterfulgt af en trecifret webstedskode, og den firecifrede udvidelse skaber en ikke-overlappende forkortet opkaldsvane mellem websteder.
| Websted | Udvidelsesområde | Webstedskode | Enterprise-sortiment |
|---|---|---|---|
| NYC | 2XXX | 202 | 8 202 2XXX |
| SFO | 3XXX | 203 | 8 203 3XXX |
| RTP | 2XXX | 204 | 8 204 2XXX |
For at muliggøre en jævn overgang bør sættet af opkaldsvaner for brugere før og efter overgangen til ideelt set være det samme. For at forberede overgangen for hvert sted skal DID-intervaller og udvidelsesintervaller (eller forkortede interne opkaldsvaner) dokumenteres. Bas eret på disse oplysninger skal styringscifferet mellem stederne vælges.
Tabellen For længelsesintervaller med fast længde viser et eksempel på tre placeringer og forlængelses områder med fast længde. Da overlappende opkaldsvaner skal undgås, er det vigtigt at sikre sig, at det første ciffer i rækkevidden ikke stemmer overens med styretumstallet for forkortet opkald mellem lokaliteter. Hvis for eksempel 8 er valgt som styringsciffer for opkald mellem lokaliteter, kan intet udvidelsesområde på noget sted starte med 8. Typisk matcher udvidelserne på et givet sted de sidste par cifre i DID'erne, der er tildelt den pågældende placering. For at undgå konflikter kan det første ciffer i udvidelsen ændres. Hvis for eksempel DID'er i +1 408 555 8XXX-området bruges på et sted, kan 7XXX bruges til udvidelserne på det pågældende websted i stedet for at bruge 8XXX som udvidelsesområde
| Websted | Udvidelsesområde | Udvidelser | Webstedskode | Enterprise-sortiment |
|---|---|---|---|---|
| NYC | 2XXX | 2XXX | 202 | 8 202 2XXX |
| SFO | 8XXX | 7XXX | 203 | 8 203 7XXX |
| RTP | 1XX | 11XX | 204 | 8 204 11XX |
Syvcifrede opkaldsstrenge, der er opkaldt på en enhed ved hjælp af den amerikanske opkaldsplan, overlapper med et syvcifret mønster til lokal opkald i den forudindlæste amerikanske opkaldsplan. For at undgå overlapninger mellem opkaldsvaner på nettet og uden for nettet (PSTN) kan der anvendes en obligatorisk ekstern adgangskode på det pågældende sted. Hvis det eksisterende virksomhedsnummereringsskema og det tilsvarende forkortede opkald mellem websteder overlapper med mønstre i det nationale opkald, kan det under overgangen til nummereringsskemaet for at undgå overlapninger også ændres til en længere eller kortere form. Den nemmeste måde at opnå dette på er at tilføje et ekstra polstret ciffer til nummereringsskemaet. Det nye længere opkaldsskema mellem websteder skal kun vedtages af brugere, der allerede er migreret til. Brugere, der stadig er på, kan fortsætte med at ringe til syv cifre. Virksomhedsopkaldsplanen, der er aktiveret, skal i dette tilfælde sikre, at den forkortede syvcifrede opkald fra Unified CM til bliver omdannet til enten +E.164 eller til det forkortede opkaldsformat, der er implementeret på. Dette skal gøres, før du sender opkaldet til den lokale gateway.
Den syvcifrede opkald i tabelovergangen viser et eksempel på denne omnummerering. I dette eksempel bruger forkortet opkald mellem websteder styretøj 8 efterfulgt af en tocifret webstedskode og en firecifret udvidelse. For at undgå syvcifret forkortet opkald mellem websteder for placeringer på, kan webstedskoderne let ændres til tre cifre ved at præfixere et vilkårligt polstring ciffer (8 i eksemplet) til de tocifrede webstedskoder, der bruges i, så opkald mellem websteder fra telefoner bruger styrecifret 8 efterfulgt af polstringcifferet 8, den gamle tocifrede webstedskode og den firecifrede udvidelse. Brugere på behøver ikke at huske nye webstedskoder; de behøver kun at huske at bruge 88 som præfiks til opkald mellem websteder i stedet for 8 på.
| Websted | Udvidelser | Webstedskode | Enterprise-sortiment | Site ode | 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 |
I et scenarie med forskellige virksomhedsnummerformater aktiveret, og hvis virksomhedsnumre vises som oplysninger om den opkaldende part for opkald fra til (for eksempel - Opkald fra enheder uden DID), er det vigtigt også at implementere en kortlægning mellem de forskellige nummerformater for oplysninger om den opkaldende part for at sikre, at tilbagekald fungerer. Denne kortlægning kan opnås ved at bruge transformationsmønster for opkaldsparti på bagagerummet mellem og den lokale gateway.
Optagelse
En veludviklet opkaldsoptagelsesløsning kræver nøje overvejelse af flere centrale designelementer for at sikre, at den stemmer overens med organisatoriske mål, lovkrav og tekniske begrænsninger. To af de mest kritiske beslutninger involverer udvælgelse af udbydere og valg af region, som begge kan være nødt til at skræddersys globalt og tilsidesættes på bestemte steder, baseret på forretningsbehov.
1. Valg af udbyder af opkaldsoptagelse
Valg af den passende udbyder af opkaldsoptagelser er grundlæggende for at opfylde forret ningsmæssige mål og sikre tilpasning af funktioner på tværs af organisationen:
-
Valg af global udbyder: Organisationer udpeger typisk en primær udbyder af opkalds optagelser på globalt niveau, hvilket sikrer konsistens i funktionssæt, overholdelse og support på tværs af alle lokationer
-
Placeringsbaserede tilsidesættelser: I scenarier, hvor bestemte lokal iteter eller regioner har unikke forretningsbehov eller lovkrav, kan det være nødvendigt at tilsidesætte det globale udbydervalg og angive alternative udbydere til disse lokaliteter. Denne fleksibilitet understøtter forskellige overholdelsesmandater og lokale operationelle behov
-
Forretningskrav: Valget af udbyder bør være drevet af en vurdering af virksomhedsdrivere såsom overholdelse af lovgivningen (eksempel - MiFID II, HIPAA), kvalitetssikring, tvistbilæggelse eller uddannelsesbehov
-
Funktionstilgængelighed: Udbydere bør evalueres ud fra deres evne til at levere krævede funktioner, såsom realtidsovervågning, søge- og afspilningsfunktioner, kryptering, opbevaringspolitikker, integration med analyseplatforme og support til forskellige opkaldstyper (indgående, udgående, interne).
2. Valg af region
Det er afgørende for overholdelse og ydeevne at bestemme det område, hvor opkaldsoptagelser gemmes og behandles:
-
Valg af globalt område: Som standard kan organisationer vælge et enkelt område til lagring af opkaldsoptagelser for at forenkle administration og styring
-
Lokationsbaserede områdetilsidesættelser: Når love om dataopholdssted eller virksomhedspolitikker kræver det, kan det være nødvendigt at tilsidesætte den globale regionindstilling for bestemte placeringer og sikre, at opkaldsoptagelser gemmes og behandles inden for de krævede geografiske grænser
-
Krav til dataopholdssted: Designet skal tage højde for internationale og lokale databeskyttelsesregler (såsom GDPR, CCPA eller landespecifikke mandater), som kan diktere, hvor og hvordan opkaldsoptagelser opbevares.
Et andet kritisk aspekt, der skal behandles under planlægningen og designet af en opkaldsoptag elsesløsning til, er estimering af lagerbehov. Nøjagtig forudsigelse af lagerbehov er afgørende for at sikre, at der er tilstrækkelig kapacitet til rådighed til at understøtte igangværende forretnings drift, opretholde overholdelse og undgå serviceforstyrrelser.
Flere nøgleparametre bør overvejes, når det forventede lagerbehov bestemmes:
-
Volumen af optagede opkald: Vurder det forventede antal opkald, der vil blive optaget inden for et givet tidsinterval (f.eks. pr. dag, uge eller måned). Dette omfatter ikke kun eksterne opkald, men også intern kommunikation, hvis det kræves af forretningspolitik eller lovgivningsmæssige mandater
-
Gennemsnitlig opkaldsvarighed: Beregn den typiske længde af optagede opkald, da længere opkald vil forbruge mere lagerplads. Variationer i opkaldsvarighed på tværs af forskellige afdelinger eller brugergrupper bør også medregnes i estimatet
-
Opbevaringsperiode: Definer, hvor lang tid optagelser skal opbevares, hvilket ofte er dikteret af organisatoriske politikker eller eksterne regler (f.eks. branchespecifikke overholdelsesstandarder). Længere opbevaringsperioder øger det samlede opbevaringsbehov
-
Vækstprognoser: Overvej forventet vækst i opkaldsmængder eller udvidelse af registreringsomfanget, som kan skyldes virksomhedsskalering, nye lovkrav eller onboarding af yderligere brugere eller lokationer.
Ved grundigt at analysere disse parametre kan organisationer udvikle en robust storagestrategi, der sikrer skalerbarhed, omkostningseffektivitet og overholdelse af lovgivningen for deres opkaldsoptagelsesløsning. Det anbefales også regelmæssigt at gennemgå og justere lager allokeringer, efterhånden som brugsmønstrene udvikler sig over tid.
Nødopkald
Kravet om at dirigere et nødopkald til det relevante forsendelsescenter er et krav for enhver opkaldstjeneste, der tilbyder PSTN-service. Med er routing af nødopkald hjemmehørende i løsningen og inkluderer support til alle nationale alarmnumre i de lande, der understøtter. Routingen af et nødopkald ind er baseret på den placering, der er defineret inden for og PSTN-adgangsmetode for lokaliteten. Alarmnumrene i er foruddefinerede og specifikke for det land, som brugerne og enhederne er implementeret i.
Der er to metoder til at levere nødopkald. Der er en grundlæggende rutetjeneste for nødopkald og en forbedret nødopkalds routingstjeneste. Den grundlæggende rutetjeneste for nødopkald bruger et administratorvalgt nummer til at identificere placeringen og opkaldsruten for at nå nødtjenester. For grundlæggende nødopkald er opkaldsstien typisk gennem kundens PSTN-mulighed for det pågældende lokation. har også forbedret nødopkaldsrouting designet til implementeringer i USA og Canada, der har lovgivningsmæssige overholdelseskrav, der kræver brug af en landsdækkende udbyder til at levere nødopkald til det korrekte forsendelsescenter.
Alle kunder skal som minimum implementere den grundlæggende nødopkaldskonfiguration. Grundlæggende nødopkald kræver, at der tildeles mindst et kundeejet +E.164-nummer til hvert sted, der er defineret i. Ved grundlæggende nødopkald vil hver placering blive defineret af en gadeadresse, som politi, brand- eller ambulancetjenester sendes til i nødstilfælde. I de fleste tilfælde er hovednummeret for placeringen det bedste valg til at repræsentere den fysiske placering af nødsituationen. Typisk koordineres tildelingen af adressen til+E.164-nummeret med PSTN-udbyderen. Billederne nedenfor viser tildelingen af hoved nummeret, der skal bruges som nødopkaldsnummer for Richardson-placeringen.
I de fleste situationer er en bygningsadresse tilstrækkelig til afsendelsesadressen for stedet. Men hvis der er behov for yderligere placeringsoplysninger for bestemte brugere eller enheder , kan en administrator bruge den samme proces, der er beskrevet ovenfor, og tildele disse enheder til en bestemt adresse eller en mere præcis placering inde i adressen (som et gulv eller et rum). Under Brugeradministration i giver fanen Op kald mulighed for, at et bestemt nummer kan bruges til en bruger og dennes enheder til at få en bestemt afsendelsesadresse. Følgende billeder illustrerer, hvordan et bestemt nummer kan tildeles en enhed. Administratoren er ansvarlig for at sikre, at det nummer, der bruges af enheden, får tildelt den korrekte afsendelsesadresse. Adres setildelingen udføres typisk gennem PSTN-udbyderen af den pågældende placering.
Til USA-baserede telefoniinstallationer, der skal levere forbedrede nødopkald sløsninger, bruger RedSky's Horizon Mobility integreret i til nødopkaldsrouting. Når du bruger RedSky til opkaldsrouting, skal en administrator tilmelde sig en konto via Cisco og konfigurere de relevante oplysninger i Op kald -> Serviceindstillinger for at aktivere denne funktion. Når RedSky- tjenesten er aktiveret på systemniveau, aktiverer en administrator RedSky- tjenesten på hvert placeringsniveau. Aktivering af forbedret nødopkald på et sted aktiverer tjenesten for alle enheder, der er tildelt den pågældende placering. Enheder, der understøtter forbedret nødopkald, er Cisco MPP-telefoner, Cisco PhoneOS-telefoner og Ciscos.
Der er to indstillinger til aktivering af forbedret nødopkald på et sted. Til lad RedSky at modtage netværksforbindelsesoplysninger og testopkald skal bruges til at kontrollere, at RedSky-konfigurationen til enheds- og infrastrukturkortlægninger er korrekt. Denne indstilling gør det også muligt at foretage testopkald til 933 for at udføre placerings bekræftelse ved hjælp af RedSkys IVR-system til at aflæse placeringen af den, der ringer op. Selvom dette dokument ikke dækker RedSky-konfigurationen til placeringssporing, skal en administrator ALTID teste deres placeringsopdagelse inden aktivering af nødop kald for at rute til RedSky. Når testen er afsluttet og verificeret som nøjagtig, dirigerer administratoren opkald til RedSky ved at skifte rutens nødopkald til RedSky. Denne skift dirigerer alle nødopkald til placeringen til RedSky til levering til telefonsvareren for placeringen.
Indstillingerne for udvidede nødopkald gælder også for klienter både lokalt og eksternt. Når det er lokalt, kan det spores på samme måde, som skrivebordstelefoner spores. Når brugeren er uden for det lokale miljø, vil brugeren være i stand til at indstille sin placering dynamisk direkte i. Du kan finde flere oplysninger om nødopkald under Ud videt nødopkald til.
Licensering
Der er flere muligheder for at tildele licenser til brugere.
Manuel tildeling gennem
Administratorer tildeler licenser manuelt til individuelle brugere via grænsefladen.
Administratorer kan redigere servicelicenser for individuelle brugere og tildele opkaldslicenser direkte.
Automatiske licenstildelingsskabeloner
Brug licenstildelingsskabeloner til automatisk at tildele licenser til brugere baseret på gruppe- eller organisationsindstillinger.
Automatisk licensering kan udføres ved hjælp af katalogsynkronisering eller manuelle brugeropdateringer, men brugerne skal have et gyldigt +E.164-formateret telefonnummer, og telefonnumrene skal findes på et sted inden brugerklargøring. Hvis betingelserne ikke er opfyldt (f.eks. ugyldigt telefonnummer format), vil licenser ikke blive tildelt.
Massetildeling via CSV-skabelon
Upload en CSV-fil med brugeroplysninger og licenstildelinger for at tilføje eller ændre flere brugere på én gang.
CSV-import understøtter tilføjelse af op til 20.000 brugere og tildeling af licenser, men licenser kræver specifikke felter som telefonnummer og udvidelse.
API-baseret tildeling
Brug API'er til programmatisk at tildele licenser og administrere brugere.
understøtter API-operationer til bruger- og licensadministration (People, SCIM 2.0 og Licenses API'er), som kan udnyttes til automatisering af licenstildeling. License- API'en tillader samtidig tildeling af licenser, telefonnumre og udvidelser.
| Tildelingsmetode | Fordele | Ulemper |
|---|---|---|
| Manuel gennem | Enkelt for få brugere. Tillader præcis og detaljeret kontrol over licenstildeling. | Ikke skalerbar, tidskrævende Tilbøjelig for menneskelige fejl under manuel indtastning. |
| Automatiske licensskabeloner | Skalerbar Reducerer manuelle fejl Kan anvendes på nye og eksisterende brugere. | Kræver gyldige telefonnumre og placeringer. Mere kompliceret at op sætte Kræver også brugergrupper pr. gruppe af brugere med tilsvarende licenskrav. |
| Masseoverførsel af CSV | Effektiv til store brugersæt Tillader samtidig tildeling af licenser, telefonnumre og udvidelser. | Kræver omhyggelig CSV-formatering Potentiale for fejl, hvis telefon numre eller udvidelser mangler eller er forkerte. |
| API-baseret tildeling | Automatiserbar, fleksibel. Tillader samtidig tildeling af licenser, telefonnumre og udvidelser. | Kræver udvikling og API viden. |
Tabellen Brugerklargøringsindstillinger - resumé opsummerer brugerklargøringsindstillinger og deres fordele og ulemper. Denne oversigt hjælper med at vælge den bedste licenstildelingsmetode baseret på kundens organisationsstørrelse, automatiseringsfunktioner og brugerklargørings processer og krav.
Hvor det er muligt, anbefaler Cisco at tildele opkaldslicenser ved hjælp af licensskabeloner. Dette kræver, at for hver gruppe af brugere, der kræver et unikt sæt licenser (Eksempel - Standard vs. Professionel) eksisterer en gruppe med de respektive gruppemedlemskaber. Som beskrevet i afsnittene Brugergrupper kan brugergrupper defineres manuelt i eller synkroniseres fra en virksomhedsmappe. En kombination af begge tilgange er mulig.
Brugere, der tilhører flere grupper, får licenser fra alle opgaver, der anvendes på alle deres grupper. Dette gør det muligt at bruge licensspecifikke sikkerhedsgrupper i virksomhedsmappen til at administrere licenstildeling, hvor den resulterende brugerlicenstildeling styres af foreningen af gruppemedlemskaber.
Du kan finde flere oplysninger under Konfigurere automatiske licenstildelinger i Control Hub og Konfigurere skabeloner til automatisk licenstildeling til Webex Calling brugere.
Licenskrav
Dette afsnit dækker kun relaterede licenser. Andre licenstyper (Eksempel - Webex-enhedsregistrering, meddelelser, møder) er ikke dækket. Som en del af designprocessen skal licenskravene fastlægges. Licenstællinger for følgende licenstyper skal beregnes:
-
Standard: antal individuelle brugere, der kræver standardtelefonfunktioner.
-
Profession el: antal brugere og arbejdsområder, der kræver avancerede telefon funktioner. Virtuelle linjer og gruppe voicemail har ret til et forhold på 1:1 for hver professionel licens. I sjældne tilfælde, hvor antallet af krævede virtuelle linjer eller gruppebeskeder overstiger antallet af brugere og arbejdsområder, der kræver avancerede telefonif unktioner, skal der tages højde for yderligere professionelle licenser.
-
Arbejdsområde til fællesområde: antal fælles brug eller fællesarealer, der kræver standardopkaldsfunktioner.
-
Kundeservice: antal agenter og vejledere, der kræver Customer Assist-funktioner. Kundeservice inkluderer Professional-licensen.
-
Rutelistek ald: antal krævede Cloud Connected PSTN-opkald mellem lokale brugere og/eller specialiserede tredjepartsprogrammer i det lokale miljø.
-
Attendant Console: antal brugere, der har brug for adgang til den ledsagende konsolklient.
-
Cisco-opkaldsplan (udgående opkaldsplan): antal brugere, der har brug for et PSTN- nummer og/eller adgang til udgående PSTN-opkald til Cisco PSTN-tjenesten.
Der er ingen dedikeret licenstype til professionelle arbejdsområder. Professionelle arbejdsområder bruger en Professional-licens.
Arbejdsområder, der kun er Hot-desk, tilbyder hot-desking-værtstjenesten og nødopkald fra hot-desking-værten og kræver ingen licens. Du kan finde flere oplysninger i Tilføj og administrere enheder, der kun fungerer som hot desk.
Hvis du vil bestemme den krævede licenstype for hver bruger og arbejdsområde baseret på de nødvendige funktioner, skal du se Funktioner, der er tilgængelige efter licenstype for Webex Calling.
For at skelne mellem funktionalitet, der tilbydes af opkaldskøer kombineret med den professionelle licens i modsætning til kundeservice, se sammenligning af op Webex Calling kald skø og kundeassistentfunktioner.
Brugerklargøring
Når du klargør brugere i Webex, er der flere tilgængelige muligheder, der hver især passer til forskellige organisatoriske behov og miljøer:
-
Manuel klargøring: Administratorer kan tilføje og administrere individuelle brugere direkte indeni. Denne metode er ligetil, men bedst egnet til små organisationer eller begrænsede bruger ændringer.
-
Masseklarering via CSV: For større brugerbaser kan administratorer importere og opdatere brugere i bulk ved at uploade CSV-filer til. Dette muliggør effektiv styring af op til tusindvis af brugere på én gang.
-
Indstillinger for mappesynkronisering:
Directory Connector: Dette er et automatisk synkroniseringsværktøj, der bruges i Microsoft Active Directory miljøer. Det synkroniserer brugerkonti, grupper og attributter på en planlagt basis (time, dagligt eller ugentligt). Det understøtter multi-domæne og multi-forest Active Directory opsætninger og kan synkronisere profilbilleder og rumobjekter.
Guide@@ appen Entra ID (Azure AD): Denne metode er designet til organisationer, der bruger Microsoft Entra ID (Azure AD) og giver automatisk synkronisering i næsten realtid af bruger konti og attributter direkte fra Entra ID til. Det er fuldt administreret indeni og kræver minimal opsætning.
SCIM 2.0-applikationer: For ikke-Microsoft-miljøer eller andre identitetsudbydere som Okta eller Duo muliggør SCIM-baserede synkroniseringsapps automatisk brugerklargøring og afklaring med attributkortlægning og gruppesyn kronisering.
-
Unified CMbrugersynkronisering: Denne indstilling gør det muligt at oprette brugerkonti baseret på eksisterende slutbrugere ved at synkronisere fra til. Dette kræver, at Cloud Connected UC (CCUC) kører på klyngerne i det lokale miljø. Det anbefales dog generelt at synkronisere brugere fra et centraliseret skybibliotek som Entra ID snarere end direkte fra.
-
API-klargøring: Offentlige API'er (People, SCIM 2.0) kan bruges til at klarlægge brugere. Den største fordel ved at bruge API'er er muligheden for at integrere brugerprovisionering med andre virksomhedssystemer.
Denne oversigt og tabel afspejler de vigtigste brugerklargøringsindstillinger, deres fordele og begrænsninger for at hjælpe dig med at vælge den bedste tilgang til din organisations behov.Tabel 6. Brugerklargøringsindstillinger for Tilvejebringelsesmetode Beskrivelse Fordele Ulemper Håndbog Opret/administrere brugere individuelt i Enkel for få brugere; ingen infrastruktur nødvendig Ikke skalerbar; tidskrævende for mange brugere Bulk (CSV-fil) Importer/opdater brugere i bulk via CSV i Effektiv for grupper; ingen kodning påkrævet Manuel CSV-forberedelse; mindre dynamisk Mennesker og SCIM 2.0 API Programmatisk brugeradministration via Webex API'er Fleksibel; understøtter automatisering og integration Kræver udvikling og infrastruktur Katalogsynkronisering Automatisk synkronisering fra AD, Entra ID, SCIM apps, Unified CM Automatiserer livscyklus; understøtter filtrering og kortlægning Opsætningskompleksitet: nogle af mulighederne har begrænsede funktioner eller kræver infrastruktur
Brugergrupper
Administration af brugergrupper i giver administratorer mulighed for at organisere brugere i grupper for effektiv massestyring af licenser, indstillinger, og ressourcer. Grupper hjælper med at strømline administrationen ved at anvende politikker, licenser og indstillingsskabeloner på flere brugere samtidigt i stedet for at administrere brugere individuelt.
Brugergruppestyring giver flere fordele, herunder:
-
Forenklet administration: Administrer licenser, indstillinger og politikker for flere brugere på én gang.
-
Konsist ens: Anvend ensartede indstillinger og licenser på tværs af brugere i samme gruppe.
-
Skalerbarhed: Understøtter op til 250.000 medlemmer pr. Gruppe.
-
Integration: Synkroniser grupper fra Microsoft Entra ID (Azure AD) eller Active Directory til automatiseret bruger- og gruppeadministration.
-
Fleksibilitet: Opret lokale grupper eller synkroniser sikkerhedsgrupper; administrer grupp emedlemskab manuelt eller via CSV-filer.
-
Ressourceallokering: Styr adgangen til integrerede apps og tjenester baseret på gruppemedlemskab.
De vigtigste anvendelsestilfælde for brugergrupper ved klargøring er:
-
Licenstildel inger: Tildel licenser til grupper for automatisk at levere tjenester som opkald, møder, beskeder eller hybridtjenester til gruppemedlemmer.
-
Indstillingsskabeloner: Anvend samlinger af serviceindstillinger (f.eks. beskeder, møde, opkald) på grupper for at opnå ensartet brugeroplevelse.
-
Hånd@@ tering af massebrugere: Tilføj eller fjern brugere i bulk via CSV-filer eller mappesyn kronisering.
-
Automatisering og integration: Brug API'er eller mappesynkronisering til automatiseret bruger- og gruppens livscyklusstyring.
Følgende tabel opsummerer de forskellige muligheder for at administrere brugergrupper og gruppe administration i.
| Mulighed | Beskrivelse | Fordele | Ulemper |
|---|---|---|---|
| gruppetildeling (grupper) | Opret og administrer grupper direkte i. Tilføj/fjern medlemmer manuelt eller via CSV. | Fuld kontrol over gruppemedlemskab Umiddelbar anvendelse af licenser og skabeloner Let at oprette og redigere grupper |
Manuelle opdateringer kræves Risiko for fejl i manuelle CSV-uploads Ingen automatisk synkronisering med eksterne mapper |
| Synkroniserede grupper fra Entra ID (Azure AD) eller Active Directory | Synkroniser automatisk sikkerhedsgrupper og medlemskaber fra eksterne katalog tjenester. | Automatiseret synkronisering reducerer manuelt arbejde Sikrer overensstemmelse med virksomhedsfortegnelsen Støtter store organisationer |
Kan ikke redigere gruppemedlemskab i Synkroniseringsforsinkelse op til 12 timer Indlejrede grupper kræver manuel markering |
| Grupper og SCIM 2.0 API (grupper) | Brug Grupper eller SCIM 2.0 API til programmatisk gruppe- og medlemsstyring | Automatisering og integration med andre systemer Skalerbar til store eller komplekse miljøer |
Kræver udviklingsindsats Kompleksitet afhænger af API-brug |
Mens synkroniserede grupper sikrer konsistens og tilbyder et enkelt administrationspunkt, er en hybrid tilgang, der kombinerer synkroniserede grupper og grupper (enten administreret i kontrolhub eller via API'er) mulig. Så for eksempel kan grupper til licenstildeling være synkroniserede grupper, og et separat sæt grupper kan bruges til at tildele bruger- og opkaldsskabeloner.
Denne omfattende tilgang til administration af brugergrupper gør det muligt for organisationer effektivt at administrere brugerlicenser, indstillinger, og politikker, hvilket sikrer ensartede og skalerbare samarbejdsoplevelser.
Anbefalet tilgang, når du migrerer fra til
Den primære datakilde for brugere på er databasen, som indeholder slutbrugeroplysninger. Imidlertid, er typisk ikke den autoritative kilde til brugeridentitetsstyring og endnu vigtigere vil blive lukket ned ved afslutningen af overgangen og udelukkes derfor som langsigtet autoritativ kilde til identitetsoplysninger.
Cisco anbefaler at bruge et centraliseret cloudbibliotek som Microsoft Entra ID (Azure AD) som den eneste kilde til sandhed for brugeridentiteter. Synkronisering af brugere fra Entra ID for at sikre konsistens, forenkle administrationen og understøtter Single Sign-on (SSO) funktioner.
For at sikre, at alle brugere på også er til stede i Entra ID, skal organisationer kontrollere, at brugerkontiene i svarer til konti i Entra ID. Dette kan gøres ved at eksportere brugerlister fra og sammenligne dem med Entra ID-brugerlister.
Sammenfattende er den anbefalede klargøringsmetode at synkronisere brugere fra Microsoft Entra ID (Azure AD) til Webex ved hjælp af Azure AD Wizard eller SCIM-apps. Manuel og CSV-masseklarering er tilgængelig som supplerende metoder, men er mindre skalerbar og mere fejltilbøjelig til store organisationer. At sikre, at Entra ID er den autoritative kilde, og at alle brugere findes i Entra ID, er afgørende for en vellykket migrering og ensartet bruger oplevelse på tværs af miljøer.
Overgangen fra en katalogtjeneste i det lokale miljøActive Directory, f.eks. til en cloudkatalogtjeneste, f.eks. Entra ID (Azure ID), er uafhængig af opkaldsovergangen. Cisco anbefaler, at overgangen til en cloud-katalogtjeneste afsluttes, inden opkaldsover gangen påbegyndes.
Design af brugergrupper
Efter overgangen til virksomhedsmappen fra det lokale miljø til skyen skal du indsamle de nødvendige brugergrupper, der er drevet af licens- og funktions skabelonkrav. For hvert gruppedokument:
-
Gruppenavn: entydigt navn på gruppen.
-
Licenser: licenser, der skal tildeles denne gruppe (hvis nogen) og omfang (skal licenser tildeles eksisterende brugere eller kun til nye brugere)
-
Indstillingsskabeloner: Webex App- og Brugeropkaldsskabeloner.
-
Katalogsynkronisering: Synkroniseres denne gruppe fra virksomhedsmappen, eller er dette en lokal Webex-gruppe klargjort i Control Hub eller via en API.
-
Beskrivelse: hvordan vil denne gruppe blive brugt, og hvilke brugere der skal være medlemmer af denne gruppe
Disse oplysninger vil blive brugt senere i implementeringsfasen til at oprette lokale grupper eller grupper i virksomhedsmappen og administrere bruger nes gruppemedlemskab.
Enkelt login (SSO)
Cisco anbefaler brug af SSO til brugergodkendelse. Brug af SSO har nogle overbevisende fordele, herunder:
-
Forenklet brugergodkendelse: Brugere kan logge på én gang ved hjælp af deres virksomhed soplysninger (f.eks. fra Azure ID) for at få adgang til og andre integrerede programmer, hvilket eliminerer behovet for flere adgangskoder og reducerer loginbeskeder. Dette forbedrer sikkerheden ved at sikre, at virksomhedsadgangskoder aldrig gemmes eller overføres til efter godkendelse.
-
Forenklet brugeradministration: Automatiserer oprettelse, opdateringer og deaktivering af brugerkonti baseret på ændringer i virksomhedsmappen, reducerer administrative omkostninger og sikrer, at kun autoriserede brugere har adgang.
-
Forbedret sikkerhed: SS O reducerer adgangskodetræthed og risikoen for adgangskoderelaterede brud ved at centralisere godkendelse via betroede identitetsudbydere (IDP'er).
-
Nem integration af multifaktor-godkendelse (MFA): MFA kan nemt understøttes enten gennem en Identity Access Management-løsning som Cisco Duo eller gennem MF A-understøttelse af IdP.
Der er flere muligheder for at implementere SSO for tjenester:
-
SAML 2.0-baseret SSO: Den primære protokol, der understøttes til SSO-integration, muliggør sikker udveksling af godkendelsesoplysninger mellem Id P'en og tjenesteudbyderen.
-
OpenID connect (OIDC): Under støttes som en alternativ moderne godkendelsesprotokol til SSO-integration.
-
Webex-identitet: Under støttes også som en identitetsudbyderindstilling.
SSO konfigureres og administreres centralt igennem, hvilket kræver udveksling af metadata mellem og den valgte IdP.
Efter konfiguration kan SSO testes inden for aktivering for at sikre korrekt opsætning.
Cisco understøtter integration med flere testede og almindeligt anvendte IDP'er og IAM (Identi ty Management Systems), herunder, men ikke begrænset til:
-
Cisco Duo
-
Okta
-
Microsoft Active DirectoryFøderationstjenester (ADFS)
-
Microsoft Azure
-
Ping Federate
-
OpenAM
-
F5 BIG-IP.
Disse IDP'er overholder SAML 2.0- eller OpenID Connect-standarderne og er blevet valideret for kompatibilitet med Ciscos samarbejdsløsninger.
Understøttelse af flere IdP
giver organisationer mulighed for at konfigurere SSO med flere IDP'er til at imødekomme komplekse it- miljøer såsom fusioner, opkøb eller decentrale it-afdelinger, hvor forskellige grupper bruger forskellige IDP'er. Understøttelse af flere IdP kan enten implementeres ved hjælp af Multi ple IdP-funktionen i eller gennem integration af et virksomheds-IAM-system som Cisco Duo.
Understøttelsen af flere identitetsudbydere (IdP) adresserer flere vigtige brugssager, hvor organisationer kræver fleksibel og sikker godkendelse på tværs af forskellige it-miljøer:
1. Fusioner og opkøb
Når virksomheder fusionerer eller erhverver andre, har de ofte separate it-infrastrukturer og særskilte IDP'er, der ikke kan forene sig. Flere IdP-understøttelser giver brugere fra begge organisationer mulighed for at godkende og samarbejde sikkert uden at skulle forene deres identitetssystemer med det samme.
2. Flere uafhængige it-afdelinger
Store organisationer eller offentlige institutioner kan have flere uafhængige it-afdelinger, der hver administrerer deres egen IdP. Flere IdP-funktioner gør det muligt for disse afdelinger at vedligeholde deres egne godkendelses systemer, samtidig med at brugerne får adgang problemfrit.
3. Forskellige brugergrupper eller domæner
Organisationer med forskellige brugergrupper (f.eks. medarbejdere vs. entreprenører) eller flere e-mail- domæner kan konfigurere routingregler til at dirigere godkendelsesanmodninger til den relevante IdP baseret på domæne- eller gruppemedlemskab. Dette understøtter differentierede adgangspolitikker og sikkerhed skontroller.
4. Understøttelse af forskellige godkendelsesprotokoller
understøtter SAML- og OpenID Connect (OIDC) IDP'er, så organisationer kan integrere forskellige typer identitetsudbydere i henhold til deres eksisterende infrastruktur og sikkerhedskrav.
5. Forbedret sikkerhed og overholdelse
Ved at aktivere flere IDP'er kan organisationer implementere stærkere godkendelsesmekanismer, herunder multifaktorgodkendelse (MFA) gennem integrationer som Duo, og håndhæve ensartede sikkerhedspolitikker på tværs af forskellige brugerbaser.
6. Forenklet brugeroplevelse
Brugere kan autentificere ved hjælp af deres eksisterende legitimationsoplysninger fra deres respektive IDP'er, hvilket giver en samlet logonoplevelse på trods af den underliggende kompleksitet i flere identitetssystemer.
Mens flere IdP-understøttelser giver fleksibilitet, kræver det omhyggelig koordinering mellem sikkerheds- og identitetsteams for at opretholde ensartede sikkerhedspolitikker og undgå potentielle sårbarheder.
Duo MFA med SSO til
Duo Access Gateway (DAG) kan godkende brugere ved hjælp af eksisterende lokale eller skybaserede mapper som f.eks. Active Directory (AD) og OpenLDAP. Det understøtter også integration med andre identitetsudbydere som Microsoft ADFS, Microsoft Azure, Okta, OneLogin, CAS og Shibboleth. Denne fleksibilitet giver organisationer mulighed for at bruge deres nuværende katalog infrastruktur til Webex SSO med Duo MFA.
Duo fungerer som et stærkt godkendelseslag oven på den primære mappegodkendelse. Det fungerer som en identitetsudbyder (IdP) ved hjælp af SAML 2.0 til at håndhæve tofaktorautentificering (2FA), før der gives adgang til. Duo evaluerer bruger-, enheds- og netværkskontekst i forhold til konfigurerbare politikker for at tillade eller nægte adgang, hvilket forbedrer sikkerheden ud over blot brugernavn og adgangskode. Duo giver også fleksible politikkontroller, såsom at kræve MFA ved hvert login for nogle apps og sjældnere for andre.
Fordelene ved Cisco Duo omfatter:
-
Forbedret sikkerhed: Tilfø jer phishing-resistent MFA for at beskytte adgangen, hvilket reducerer risikoen for kompromitterede adgangskoder.
-
Fleksible politikker: Tillader detaljeret kontrol over godkendelseskrav pr. program eller brugergruppe.
-
Integration med eksisterende mapper: Under støtter lokal AD, OpenLDAP, cloud- mapper og forskellige SSO-udbydere, hvilket minimerer infrastrukturændringer.
-
Brugervenlighed: Under støtter Single Sign-On (SSO) for at reducere adgangskodetræthed ved at give brugerne mulighed for at logge ind én gang og få adgang til flere ressourcer sikkert.
-
Pålidelige slutpunkter: Under støtter enhedstillidelighed for klienter på Windows og macOS, hvilket forbedrer sikkerhedsstillingen.
-
Selvbetjeningstilmelding: Inline-tilmelding og duo-prompt forbedrer brugeroplevelsen under MFA-opsætning.
Duo MFA med SSO til udnytter eksisterende mapper som Active Directory og OpenLDAP, eller cloud-identitetsudby dere, til at godkende brugere. Duos rolle er at levere en stærk, politikdrevet anden godkendelses faktor integreret gennem SAML 2.0, hvilket forbedrer sikkerheden, samtidig med at brugervenligheden opretholdes gennem SSO. Fordelene inkluderer forbedret sikkerhedsstilling, fleksibel politikh åndhævelse, problemfri integration og en bedre brugeroplevelse.
Cisco anbefaler implementering af SSO for brugere. For forbedret sikkerhed anbefales integration med Cisco Duo.
Enterprise IAM- og SSO-strategien bør implementeres, inden overgangen fra til påbegyndes.
Funktioner
har et komplet komplement af kernefunktioner, der er inkluderet i tjenesten. Dette inkluderer mange opkaldsfunktioner i virksomhedsklasse, der har været tilgængelige i mange år. Du kan muligvis ikke se 100% paritet mellem funktioner og funktioner, men som du kan se i nedenstående figur, er de vigtigste opkaldsfunktioner tilgængelige i.
Udover de mange brugerfunktioner, har kernesystemfunktioner, der er inkluderet i platformen. Disse inkluderer funktioner som autoledsagere, opkaldskøer, opkaldspark osv. Du kan se alle de tilgængelige kernesystem funktioner under Service → Opkald → Funktioner som vist i figur Webex Callingkerne funktioner.
Automatisk ledsager
Auto Attendant giver mulighed for 24/7 automatisering af håndtering af indgående opkald, hvilket giver mulighed for effektiv opkaldshåndtering uden behov for, at en person besvarer hvert opkald.
Den automatiske ledsager besvarer indgående opkald og giver den, der ringer op, en menu med muligheder for, hvor de vil dirigere deres opkald. Dette kan være til en person, en telefonsvarerboks eller en opkaldstjeneste (f.eks. Opkaldskø). Den, der ringer op, bruger telefonens opkaldstastatur til at indtaste nummeret fra menuen Auto Attendant.
Den automatiske svartjeneste understøtter følgende nøglefunktioner:
-
Forretnings- og efterarbejdsplaner
-
Ferieplan
-
Opkaldsmenuindstilling for at dirigere dine kunder derhen, hvor de skal hen
-
Tilpas hilsner
-
Opkald efter navn
-
Muligheder for viderestilling af opkald
-
Control Hub analyser og rapporter.
Du kan finde flere oplysninger i Administrer automatiske besvarelser.
Ring til Park
Call park giver brugerne mulighed for nemt at sætte et opkald på vent, så en anden bruger nemt kan hente, når de er tilgængelige til at tage det. Det frigør også den bruger, der besvarede det oprindelige opkald, til at foretage eller modtage andre opkald, mens opkaldet er parkeret.
Der er to typer opkaldsparker tilgængelige i:
-
Call park direct - gør det muligt for enhver bruger at parkere et opkald til en anden brugers udvidelse eller til en opkaldspark-udvidelse, som defineret af administratoren
-
Call park group - giver en defineret gruppe brugere mulighed for automatisk at parkere opkald mod tilgængelige parkdestinationer, der er defineret for gruppen. Disse destinationer kan være gruppemedlemmernes udvidelser eller udvidelser af opkaldsparker.
Baseret på konfiguration og parkeringstype kan brugerne hente opkald ved at <extension of parked call>ringe til *88+>, trykke på linjetasten, der er knyttet til opkaldsparkens udvidelse, eller bruge en softkey på deres IP-adresse.
En tilbagekaldelsesmulighed er tilgængelig for at tilbagekalde et parkeret opkald efter en bestemt periode til den bruger, der parkerede opkaldet, eller til en alternativ bruger.
Du kan finde flere oplysninger i Administrer opkaldsparkering i Control Hub.
Afhentning af opkald
Optagelse af opkald giver en administrator mulighed for at definere en gruppe brugere (medlemmer), der kan besvare et opkald til et andet medlems telefon. Dette giver en bruger mulighed for at besvare opkald, når deres holdkammerater har travlt og ikke kan besvare et indgående opkald.
Brugerne i en gruppe skal være på samme sted.
Brugere kan bruge enten skrivebordstelefonen eller deres skrivebordstelefon til at afhente et opkald.
-
:
-
Understøtter visuelle og lydmeddelelser
-
Meddelelse om indgående opkald
-
FAC-baseret (opkald*98) eller afhentning af opkald med notifikationer
-
Meddelelser om afhentning af opkald til multiline.
-
-
Skrivebordstelefoner:
-
Meddelelse om indgående opkald
-
Lyd klokkeslæt og visuel meddelelse gennem håndsættets LED. 6821 understøtter kun lydklokkeslæt
-
Når meddelelsestypen er valgt i er ikke ingen
-
-
Meddelelser om afhentning af opkald kun for primære linjer.
-
Du kan finde flere oplysninger i Konfigurere gruppe for afhentning af opkald.
Opkaldskø
inkluderer kun taleopkaldskøer som en del af kernefunktionerne, og enhver bruger med en Professional-licens kan være en del af en opkaldskø, agent eller supervisor. Denne funktion giver brugerne mulighed for effektivt at interagere med kunderne. Opkaldskøer understøtter en delmængde af nogle af callcen ter-kernefunktionerne som stemmekøer, tilbagekald, færdigheds- eller prioritetsrouting, agentkø styring, analyse, rapportering osv.
Ciscos opfordring til Microsoft Teams-integration giver agenter adgang til opkald og funktioner i opkaldskøen direkte fra deres Microsoft Teams-klient.
Opkaldskøer understøtter følgende nøglefunktioner:
-
Hilsner og beskeder (velkomst, komfort, hvisken osv.)
-
Hold musik
-
Tilbagekald
-
Politikker for køruting (natservice, helligdage, videresendelse)
-
Login/log ud af agentkøen
-
Administration af agentkøstatus
-
eller Desk Telefonsupport
-
Supervisor-agent overvåger, træner, pramme eller overtager via Feature Access Codes (FAC'er)
-
(administratoradgang) til:
-
køstyring
-
Agent- og køanalyse og rapportering
-
Kø-, agent- og vejlederstyring.
-
Du kan finde flere oplysninger i Konfigurere opkald skø.
har en tilføjelsesfunktion til kundeservice, der giver yderligere opkaldskøfunktioner og giver agenter og vejledere en bedre brugeroplevelse inden for. For en sammenligning af funktionerne Opkaldskø og Kundeservice, se Sammenligning af Webex Calling op kaldskø og kundeassistent funktioner.
Jagtgruppe
Hunt Groups giver mulighed for routing af indgående opkald til en bestemt gruppe af brugere gennem et forudbestemt opkaldsroutingsmønster. Dette sikrer, at opkald besvares af den rigtige gruppe af brugere eller sendes til en voicemail til opfølgning.
En stor forskel mellem Hunt Groups og Call Queues er, at opkald ikke står i kø i en jagt gruppe, så hvis ingen brugere i Hunt-gruppen er tilgængelige til at besvare opkaldet, vil det blive afbrudt, sendt til telefonsvarer eller videresendt til et andet nummer (bruger eller tjeneste).
Du kan finde flere oplysninger i Administrer jagtgrupper i Control Hub.
Driftstilstande
Funktionen Operating Modes giver virksomheder mulighed for effektivt at dirigere opkald til forskellige destinationer (brugere, telefonsvarer, opkaldstjenester som en opkaldskø). Hvor og hvornår et opkald dirigeres, er baseret på en tids plan for dagen og ugedagene, og enhver bruger kan bemyndiges til at administrere disse tilstande (tidsplaner) for at kontrollere ændringer i opkaldsrutingen.
Som et eksempel kan opkald til en opkaldskø dirigeres til en anden opkaldskø med agenter i en anden tidszone for at besvare opkald efter åbningstider, i løbet af arbejdstiden dirigeres til de lokale agenter og i ferier dirigeres til telefonsvarer til op følgning, når agenterne vender tilbage til kontoret.
En autoriseret bruger kan skifte mellem disse forskellige videresendelsesscenarier (tilstande), hvis de har brug for at ændre, hvor indgående opkald dirigeres i en bestemt periode. Disse brugere kan administrere tilstand ene gennem deres 6800/7800/8800 MPP-telefoner, 9800-telefoner eller i User Hub under Administrer tilstande.
Du kan finde flere oplysninger i Op kaldsdirigering baseret på driftstilstande i Webex Calling.
Personsøgningsgruppe
Personsøgningsgrupper giver brugerne mulighed for at foretage et envejsopkald for at sende en lydbesked til en gruppe brugere. Hver gruppe kan indeholde op til 75 målbrugere og/eller arbejdsområder, der nås ved at ringe til et foruddefineret nummer eller en udvidelse.
Når en bruger ringer til en personsøgningsgruppe, foretages der et samtidig opkald til alle de tildelte mål i gruppen, hvor den, der ringer op, kan tale deres beskeder og lægge på, når de er færdige.
Du kan finde flere oplysninger i Konfigurere en personsøgningsgruppe i Control Hub.
Optagelser
understøtter optagelse af opkald foretaget eller modtaget af en bruger. Dette kan være nødvendigt af hensyn til kvalitets-, sikrings-, sikkerheds- eller uddannelsesbehov. Som standard optages opkald i, men andre tredjeparts optagelsesudbydere kan også bruges, hvis andre optagef unktioner eller overholdelse og lovkrav er påkrævet.
Når du bruger som optagelsesplatform, administreres alle optagede opkald indeni. Fuldstændige administratorer med rollen som Compliance Officer kan spille og downloade optagelserne. Uden rollen som Compliance Officer kan administratoren kun slette optagelserne.
Du kan finde flere oplysninger om denne funktion og en liste over tredjepartsoptagelser under Administrer opkalds optagelse for Webex Calling.
Enkelt nummerrækkevidde
Enkeltnummerrækkevidde tillader opkald til en brugers telefonnummer for at ringe til flere enheder. Dette kan omfatte andre skrivebordstelefoner såvel som mobiltelefoner. Opkald kan også foretages fra disse enheder, og brugerne kan skubbe og trække opkald mellem dem.
Du kan finde flere oplysninger om denne funktion, og hvordan en administrator konfigurerer den i, under Konfigurere enkeltnummerrækkevidde (kontor hvor som helst).
Du kan finde flere oplysninger om, hvordan en bruger kan administrere og konfigurere denne funktion for sig selv i Webex User Hub (portalen), under Konfigurere enkeltnummerrække vidde (kontor hvor som helst).
Voicemail-gruppe
Voicemail-grupper giver mulighed for en delt voicemail-boks, der kan tildeles en bruger eller opkaldsroutingsfunktion. Nogle af grundene til, at en voicemail-gruppe kan være påkrævet, er:
-
Generel telefonsvarer til en afdeling eller arbejdsgruppe
-
Føj mulighed for voicemail til en automatisk ledsager eller jagtgruppe
-
Sådan sender du overløbsopkald fra en opkaldskø
-
Brugere, der kun har brug for en voicemail-boks.
Du kan finde flere oplysninger i Administrer en delt telefonsvarer og indgående fax boks for. Webex Calling
Attendant Console vises på siden Opkaldsfunktioner i Webex, men det er en tilføjelsesfunktion, der kræver køb af den ledsagende konsol licens for at bruge.
Du kan finde flere oplysninger i Kom godt i gang med Attendant Console.
Du kan finde oplysninger om alle funktioner, herunder nogle tilføjelsesfunktioner, under Funktioner, der er tilgængelige efter licenstype for Webex Calling.
Implementere
Netværksberedskab
Det første skridt i overgangen til er at sikre pålidelig og sikker internetforbindelse mellem det lokale netværk og skyen.
Da de fleste organisationer opretter forbindelse til internettet via en eller flere firewalls eller sikkerhedsenheder, er det vigtigt at validere, at de krævede trafikstrømme under støttes.
Netværks- og sikkerhedsadministratorer skal forstå disse strømme med hensyn til:
-
Retning (indgående vs udgående)
-
Protokoller (Eksempel - SIP TLS, SRTP, HTTPS)
-
IP-adresseintervaller, der bruges af tjenester
-
Portnumre, der skal åbnes eller tillades.
Dette sikrer, at virksomhedens firewalls, NAT-enheder og anden netværksinfrastruktur er korrekt konfigureret til at imødekomme trafik, samtidig med at virksomhedens sikkerhedspolitikker opretholdes.
For oplysninger om de krævede strømme, herunder IP-adresse, porte, og protokoller, se Portreferenceoplysninger for Webex Calling. Brug disse oplysninger til at konfigurere firewall, proxyer og anden netværksinfrastruktur i den eksisterende installation for at aktivere netværksstrømme.
Decentraliseret internetudbrud fra hver filial eller websted er den anbefalede tilgang til cloud-samarbejdstjenester såsom. Ved at tillade trafik at afslutte lokalt, kan denne model:
-
Reducerer forsinkelse og jitter tur/retur, hvilket forbedrer den samlede opkaldskvalitet
-
Skalerer effektivt, efterhånden som flere brugere og websteder overgår til
-
Fungerer problemfrit med SD-WAN, som dynamisk kan dirigere sessioner til det nærmeste cloud-indgangspunkt for optimal ydeevne
- Tillader at spore brugerplacering baseret på deres offentlige IP-adresse, hvilket hjælper med mediesti analyse og fejlfinding.
Derudover skal organisationer sikre tilstrækkelig internetbåndbredde på hvert websted. Bå ndbredde skal dimensioneres baseret på det forventede antal samtidige opkald, den valgte codec (f.eks. Opus eller G.711) plus overhead til signalering, retransmissioner og vækst. Dette stemmer overens med forberedelsesfasen i PPDIO-livscyklussen og skaber et solidt fundament for migration.
Indledende opsætning
Det indledende opsætningsunderafsnit inden for implementeringsfasen af implementering er grundlæggende for etablering af et velstruktureret og håndterbart cloud-opkaldsmiljø. Denne fase omfatter kritiske opgaver såsom opsætning af organisationen, indkøb og tildeling af licenser og verifikation og krav på din virksomheds domæner for at sikre korrekt brugeradministration og sikkerhed. Derudover inkluderer den klargøringslic ensskabeloner til automatisering af brugerlicenstildelinger, konfiguration af Single Sign-On (SSO) for at strømline brugergodkendelse og forbedre sikkerheden og justere service- og klientindstillinger, så de passer til organisationens politikker og brugerbehov. Gennemførelsen af disse indledende konfiguration saktiviteter sikrer, at miljøet er korrekt konfigureret til skalerbarhed, sikkerhed og problemfri brugeroplevelse, hvilket sætter scenen for efterfølgende udrulnings- og driftsfaser.
Domænebekræftelse
For at gøre det muligt at identificere brugere, der er registreret med din virksomheds e-mail-domæner på, er det vigtigt at bekræfte dine domæner. Uden domænebekræftelse vil brugerne blive tildelt en forbrugerorganisation, hvilket komplicerer brugeradministration for din virksomhed. Domænebekræftelse er et obligatorisk trin, der gør det muligt for din organisation at gøre krav på og administrere disse brugere effektivt.
Sørg for, at alle domæner, der er knyttet til dine brugeres e-mail-adresser, er verificeret. Domæne bekræftelse er ikke eksklusiv; det samme domæne kan verificeres på tværs af flere organisationer.
Du kan finde flere oplysninger om administration af domæner under Administrer dine domæner.
Gør krav på (konverter) eksisterende brugere
Når du har bekræftet dine domæner, kan du fortsætte med at gøre krav på brugere, der har registreret sig for at bruge din virksomheds e-mail-domæner, i din organisation. Denne proces konsoliderer alle brugere under en enkelt organisatorisk paraply, hvilket muliggør centraliseret styring og strømlinet administration. Ved at gøre krav på disse brugere sikrer du, at din virksomhed har fuld kontrol over brugerkonti, så du kan tildele passende licenser, konfigurere tjenester og yde den nødvendige support effektivt. Denne samlede administrationsmetode forbedrer sikkerheden, forenkler brugerklargøring og sikrer ensartet adgang til tjenester på tværs af organisationen. At hævde brugere forhindrer dem også i at blive administreret i eksterne organisationer eller forbrugerorganisationer, hvorved organisatorisk integritet og kontrol over samarbejdsressourcer opretholdes.
Du kan finde flere oplysninger om, hvordan du gør krav på brugere, under Gør krav på brugere til din organisation (konverter) brugere.
Konfigurer og test katalogsynkronisering
Hvis du vil aktivere problemfri bruger- og gruppeadministration, kan du synkronisere brugere og grupper fra din virksomhedsmappe enten Microsoft Entra ID (tidligere Azure AD) eller Microsoft Active Directory (AD) til. Denne proces sikrer, at brugeridentiteter og gruppemedlemskaber konsekvent opre tholdes på tværs af dit miljø.
For organisationer, der implementerer trinvise implementeringer, er det afgørende at kontrollere og begrænse omfanget af synkronisering under indledende udrulninger. Dette minimerer risikoen for utilsigtede ændringer og giver mulighed for målrettet test inden bredere anvendelse.
Den mest effektive metode til filtrering af, hvilke brugere der synkroniseres, er at udnytte kataloggruppemedlemskab:
| 1 |
Opret en dedikeret synkroniseringsgruppe: Opret en sikkerhedsgruppe specifikt til synkronisering (f.eks. Synkroniseringsgruppe) i din virksomhedsmappe (Microsoft Entra ID eller AD). |
| 2 |
Udfyld gruppen med målbrugere: Tilføj kun de brugere, du vil synkronisere (f.eks. en testgruppe under pilotfasen) til denne gruppe. Dette giver dig mulighed for tæt at kontrollere, hvem der er inkluderet i synkroniseringsprocessen. |
| 3 |
Konfigurer synkroniseringsaftalen med gruppebaseret filtrering: Når du konfigurerer synkroniseringsaftalen i Directory Connector eller Entra ID-klargøring, skal du konfigurere omfanget til kun at omfatte brugere, der er medlemmer af den udpegede gruppe.
|
| 4 |
Udvid gruppen efter behov: Når du går videre til bredere implementeringsfaser, skal du blot tilføje yderligere brugere eller grupper til synkroniseringsgruppen. Synkroniseringsomfanget udvides automatisk til at omfatte disse brugere, hvilket giver mulighed for kontrolleret og gradvis udrulning. Eksempel på implementeringstrin:
Referencer: Synkroniser Entra ID-brugere til Control Hub |
Konfigurer og test Single Sign-On (SSO)
Single Sign-On (SSO) forbedrer sikkerheden og forenkler brugeradgangen ved at give brugerne mulighed for at godkende én gang med deres virksomhedsoplysninger og få problemfri adgang til. understøtter SSO-integration med SAML 2.0-kompatible IDP'er, herunder Microsoft Entra ID (tidligere Azure AD), Active Directory (AD) fødererede løsninger og forskellige tredjeparts-IDP'er.
På dette tidspunkt skal den designede SSO-opsætning implementeres og testes.
Referencer:
Integration af enkelt logon i kontrolhubben
konfigurere enkelt logon til webex-administration
Anskaffe, tilvejebringe og verificere licenser
Som en del af den indledende opsætning for, er det vigtigt at anskaffe, levere og verificere de relevante licenser for at aktivere og administrere tjenester effektivt. Indkøbsprocessen involverer valg af licen styper baseret på brugerroller og arbejdsbelastninger, f.eks. Professional-, Standard- og Workspace- licenser. Licenser genereres og leveres via Ciscos softwareplatforme eller gennem partnere. Efter indkøb og klargøring skal det korrekte antal licenser verificeres i. Denne proces sikrer, at organisationen har de korrekte licenser aktiveret og klar til brug i installationen.
Som en del af den indledende licensopsætning i er det vigtigt at konfigurere organisationsbaseret automatisk licensering for at strømline licenstildelingen til nye brugere. Denne opsætning gør det muligt automatisk at tildele licenser, når brugere føjes til organisationen, hvilket eliminerer behovet for manuel licens tildeling. Når du konfigurerer automatisk licensering på organisationsniveau, skal du vælge de tjenester, der skal tildeles, og definere omfanget, f.eks. anvende licenser til kun fremtidige brugere eller også inkludere eksisterende brugere.
Men hvis din installationsplan indebærer brug af automatisk licensering på gruppeniveau i stedet, kan du vælge ikke at tildele licenser på organisationsniveau for at undgå konflikter eller duplikerede licenstil delinger. Med automatisk licensering på gruppeniveau tildeles licenser baseret på gruppemedlemskab. Brugere i flere grupper modtager licenser fra alle relevante gruppetildelinger.
Gruppebaseret licenstildelingskonfiguration skal udføres, når mappesynkroniseringen er fuldført, så synkronis erede grupper findes og kan bruges til licenstildeling.
Specifikt kræver automatisk licenstildeling yderligere klareringsoplysninger såsom brugerplacering og tildeling af telefonnummer. Brugerens arbejdstelefonnummer skal være i +E.164-format, forudbestemt og tildelt en gyldig placering for at licensen kan aktiveres automatisk. Hvis disse betingelser ikke er opfyldt, vil brugeren ikke blive forsynet med tjenester automatisk og kan kræve manuel indgriben.
Sammenfattende skal du konfigurere organisationsbaseret automatisk licensering til nye brugere, hvis du vil have en bred licenstildeling for hele organisationen. Hvis du foretrækker mere detaljeret kontrol eller har forskellige licensbehov pr. gruppe, skal du konfigurere automatisk licensering på gruppeniveau og undgå at tildele licenser på organisationsniveau for at forhindre overlapning og sikre korrekt licensadministration.
Webex Calling serviceindstillinger
Det er vigtigt at foretage en omfattende gennemgang og konfiguration af de globale service indstillinger inden for.
Begynd med at få adgang til og navigere til indstillingsafsnittet. Undersøg omhyggeligt hver konfigurerbar indstilling, herunder, men ikke begrænset til, intern opkaldskonfiguration, nødopkaldsparametre, opkaldsrouting politikker, telefonsvarerstyring og enhedens standardindstillinger.
Juster disse globale indstillinger, så de afspejler organisationens politikker og designbeslutninger.
Også opsætningsindstillinger og bruger- og appskabeloner.
Pilotmigration
I implementeringsfasen repræsenterer udførelse af en pilotmigration en kritisk milepæl i valideringen af overgangen fra til. Denne pilot involverer klargøring af en repræsentativ undergruppe af brugere på tværs af en eller flere placeringer på platformen, hvilket sikrer, at den valgte population afspejler forskellige brugssager og organisatoriske roller. Parallelt med brugermigrering skal vigtige samarbejdstjenester, herunder telefonsvarer, automatiske beskeder, opkaldskøer og jagtgrupper, overføres til deres ækvivalenter for at opretholde forretningskontinuitet og servicefunktionalitet.
Pilotmigreringen skal udnytte den samme kombination af Cisco-leverede værktøjer og tredjepartsmigreringsværktøjer, som er planlagt til den bredere organisatoriske implementering, hvilket sikrer, at processer, automatiseringsarbejdsgange og integrationspunkter valideres grundigt under repræsentative forhold.
De primære mål med denne pilotudvikling er to: For det første at validere og forfine ende-til-slut-overgangsprocesserne, herunder arbejdsgange for brugerklargøring, datami greringsprocedurer og slutpunktskonfigurationer; og for det andet at verificere funktionaliteten af migrerede tjenester under virkelige driftsforhold.
Denne trinvise tilgang gør det muligt for projektteamet at identificere og afhjælpe eventuelle tekniske eller proceduremæssige problemer i et kontrolleret miljø, indsamle brugerfeedback om den nye platformsoplevelse, vurdere effektiviteten af udvalgte migreringsværktøjer og etablere tillid til migreringsm etoden, inden de fortsætter med bredere organisatorisk implementering.
Den indsigt, der er opnået i denne pilotfase, er medvirkende til at optimere efterfølgende migrationsbølger og sikre en gnidningsl øs, risikoreduceret overgang for hele virksomheden.
Køb PSTN
For at anskaffe PSTN-tjenester til, vælg først en PSTN-tilslutningsindstilling i.
Hvis en organisation planlægger at opretholde hybrid dobbelt opkaldskontrol (fase 1 i figur Trinvis opkald sovergang: Hybrid og Cloud) enten midlertidigt eller på ubestemt tid, skal de installere en eller flere lokale gateways til PSTN i det lokale miljø for at tillade opkald mellem og slutpunkter.
Hvis en fuld overgang (fase 2) til skyen er slutmålet inklusive PSTN, kræves enten en Cisco-opkaldsplan eller en Cloud Connect for mulighed for PSTN.
Arbejd med din valgte udbyder for at bestille og portere telefonnumre, før du konfigurerer dem. Bestilling af telefonnumre eller initiering af portordrer er kun krævet/muligt for PSTN og Cloud Connect i det lokale miljø for. For Cisco-opkaldsplaner startes bestilling og porting fra Control Hub, så snart placeringen er oprettet, og i lande, hvor Cisco Calling Plan er tilgængelig. Du kan finde flere oplysninger om Cisco-opkaldsplaner under Kom godt i gang med C isco-abonnementerne.
Som en del af implementeringen af PSTN skal du sikre dig, at din udbyder har aktiveret både indgående og udgående PSTN-tjenester for din placering. Derudover skal du udføre testopkald for at kontrollere, at opkald dirigeres korrekt via den valgte PSTN-forbindelse.
Konfigurer placeringer
Før du føjer brugere og enheder til, skal du angive opkaldssteder. For hver placering skal der indtastes en gyldig gad eadresse. I USA og Canada valideres denne adresse og bruges af platformen til at sende PIDF-LO-placeringsoplysninger til nødopkald.
Når du konfigurerer placeringer, der bruger PSTN i det lokale miljø, skal du konfigurere de lokale gateways i overensstemmelse hermed. I skal der oprettes en trunk og en rutegruppe for hver lokal gateway, og ruteg ruppen tildeles derefter som PSTN-valget for placeringen. Cisco anbefaler kraftigt altid at vælge en rutegruppe som PSTN-valg, da denne tilgang giver dig mulighed for nemt at tilføje yderligere trunker i fremtiden, hvilket understøtter både skalerbarhed og redundans. Cisco anbefaler også at aktivere dual-identity og P-Charge-Info support på alle PSTN-trunker, da dette forenkler identifikationen af den fakturerbare part for udgående direkte eller omdirigerede opkald. Hvis din PSTN-udbyder bruger en anden header til fakturering, kan du kopiere oplysningerne fra P-Charge-Info-overskriften på den lokale gateway til den krævede faktureringsoverskrift.
For steder, der bruger Cloud Connect til eller Cisco Calling Plan som deres PSTN-mulighed, skal du blot vælge det respektive PSTN- valg for placeringen under opsætningen. Hvis placeringen bruger enten Cloud Connect til eller PSTN i det lokale miljø, skal du tilføje de telefonnumre, der blev bestilt i det foregående trin. Numre kan tilføjes som inaktive, hvis du ikke vil have dem inkluderet i op kaldsrouting med det samme; du kan aktivere disse numre senere, når de tildeles brugere eller funktioner.
Det er vigtigt altid at indstille hovednummeret for hver placering. Hovednummeret kan tildeles enten en bruger eller en funktion, såsom en automatisk ledsager. For at aktivere voicemail på stedet skal du sørge for at indstille telefon svarerens pilotnummer, også kendt som stemmeportalnummeret.
Yderligere indstillinger for opkaldssteder omfatter konfiguration af nø dopkaldsoplysninger såsom nødopkaldsnummeret, meddelelses muligheder og forbedrede nødopkaldsfunktioner. Du bør også gennemgå og justere optagelsesindstillinger, sprogindstillinger og enhedskon figurationer efter behov for hver placering. Hvis din organisation bruger forkortet internetopkald mellem websteder med virksomhedssignifikante numre, skal du huske at konfigurere en unik webstedskode for placeringen i de interne opkaldsindstillinger. Endelig, hvis ekstern opkald kræver et udgående opkaldsciffer, skal du sørge for at indstille dette i indstillingerne for ekstern opkald . Når der er konfigureret et ciffer for udgående opkald, anbefaler Cisco, at håndhævelse af udgående opkaldscifre aktiveres for at sikre konsistens.
Integration med opkaldskontrol i det lokale miljø
Hvis du vil integrere med opkaldskontrol i det lokale miljø, er det nødvendigt at konfigurere trunker, rutegrupper, virksomhedsopkaldsplaner og både placeringsindstillinger og globale indstillinger. Begynd med at konfigurere trunker og lokale gateways, der er beregnet til sammenkobling med det lokale opkaldskontrolsystem. Dette trin er kun påkrævet, hvis dedikerede trunker er nødvendige. Hvis eksisterende trunker og rutegrupper er tilstrækkelige til installationen, kan de genbruges til sammenkoblingen i det lokale miljø uden yderligere konfiguration.
Når trunkerne og rutegrupperne er oprettet, skal du fortsætte med at oprette virksomhedens opkaldsplaner og tildele den relevante rutegruppe som destination for hver opkaldsplan. Når integrationen involverer flere lokale opkaldsstyringssystemer, der er forbundet via forskellige trunker, kræves der flere opkaldsplaner. Det er vigtigt at sikre, at disse opkaldsplaner kun indeholder de mønstre, der er nødvendige for at dirig ere opkald til lokale destinationer.
Hvis installationen kræver understøttelse af ukendt udvidelsesrouting, skal denne funktion være aktiveret på placeringsniveau. Når routing af ukendt udvidelse er aktiveret, skal du desuden angive den maksimale ukendte forlængelseslængde i afsnittet Opkal dsdirigering mellem og lokaler i indstillingerne for opkaldstjenester i. Dette sikrer problemfri opkaldsrouting og korrekt håndtering af udvidelsesbaserede opkalds scenarier i dit integrerede miljø.
Overfør brugere i batcher
Når du overfører brugere fra til, kan du muligvis ikke flytte alle brugere på samme tid. Dette kan skyldes flere årsager, herunder men ikke begrænset til antallet af websteder eller brugere, hvor lang tid det tager at overføre et websted og/eller en gruppe af brugere på én gang, begrænset it- eller webstedsressource til at understøtte ændringsvinduet, varigheden af ændringsvinduet, ændringens kompleksitet osv.
Når du overfører brugere i faser, er det vigtigt at identificere, hvilke brugere der skal migrere sammen i samme batch. Det primære mål er at migrere brugere sammen, der har afhængigheder med hinanden for deres opkaldstjenester og funktioner. Du vil sikre, at alle deres opkaldsfunktioner (Eksempel - Opkaldskøer) er fuldt funktionsdygtige, som de var før overgangen til.
Selvom du implementerer opkaldssamarbejde mellem og med lokale gateways, kan du ikke opdele delte tjenester eller funktioner på tværs af denne forbindelse. Derfor skal du identificere afhængighederne mellem brugere ved at se på funktioner som:
-
Overvågning af andre brugere ved hjælp af BLF'er
-
I samme jagtpilot, opkaldskø osv
-
Delte linjer
-
Brug af opkaldsafhentning
-
Brug af de samme call-park-numre
-
Intercom
-
Eksekutiv/Administrator.
Et eksempel ville være en bruger, der er en del af en Hunt-gruppe, der overgår til. Denne bruger overgår til med Hunt Group og med alle andre medlemmer af Hunt Group. Derfor kan Hunt Group og dens medlemmer efter overgangen med succes besvare opkald på den nye platform.
Dette bliver mere udfordrende, når brugerne er forbundet til forskellige grupper af brugere for forskellige opkaldstjenester og funktioner. Dette kræver overgang af mere end en gruppe brugere og en opkaldstjeneste til på samme tid.
Brug outputtet fra værktøjet Migration Insights eller tredjepartsværktøjet, som du brugte i forberedelsesfasen, til at bestemme, hvilke brugere og funktioner der skal grupperes sammen. Dette output skulle have været brugt til at udvikle din overførselsplan og vil give dig indsigt i, hvordan du grupperer brugere og funktioner, der skal overgå sammen.
De vigtigste trin, når du overgår en batch af brugere, er:
-
Identificering af brugere, der skal migreres sammen
-
Bekræft, at alle brugere er inde
-
Bekræft, at alle TN'er for brugerne findes i
-
Bekræft korrekt telefonnummerformat i mappen
-
Sørg for, at licens- og indstillingsskabelonen for brugergrup perne er konfigureret korrekt
-
Verificering eller konfiguration af alle opkaldstjenester og -funktioner for gruppen af brugere (før eller under overgangen, alt efter hvad der er relevant)
-
Føj brugere til gruppen af opkaldsaktiverede brugere i virksomhedsmappen
-
Udnyt værktøjer - bruger- og funktionsmigreringsværktøjer og/eller tredjepartsværktøjer
-
Deaktiver/slet bruger/enhedens katalognummer og opkaldsfunktioner/tjenester til efter overgangen.
Efter overførsel af en gruppe brugere skal du teste en undergruppe af brugerne for at kontrollere, at alle deres opkaldsfunktioner og -tjenester fungerer korrekt. Hvis opkaldsfunktioner som opkaldskø, jagtgrupper osv. overføres med gruppen af brugere, skal du teste disse opkaldstjenester for korrekt funktionalitet.
Arbejdsområder
I refererer et arbejdsområde til en delt placering (f.eks. et mødelokale, mødelokale eller et hot desk), der kan tildeles enheder, udvidelser og brugere. I modsætning til traditionelle Unifed CM- telefoner er arbejdsområder:
-
Placeringscentreret: bundet til fysiske rum.
-
Enhedsfleksibel: kan have en eller flere enheder (skrivebordstelefoner, tavler osv.).
Når arbejdsområder er blevet identificeret som en del af overgangen til, kan de tilføjes under Enheder. Hvert arbejdsområde skal have en enhedstildeling, og hvis de allerede er iUnified CM, skal de nulstilles eller genklargøres til dem. funktioner som telefonsvarer, viderestilling af opkald og afhentning af opkald kan aktiveres eller deaktiveres, og politikker kan anvendes til videoopkald, opkaldsparkering og mobilitet efter behov. Test hvert arbejdsområde ved at foretage interne og eksterne opkald, teste video-, konference- og mobilitets funktioner. Endelig skal du fortælle brugerne om eventuelle relevante processer for arbejdsområdeenheder og bookinger.
Du kan finde flere oplysninger om arbejdsområder i under Arbejdsområder.
Tilvejebringelsesenheder
Telefoner, der i øjeblikket er registreret til, skal migreres til som en del af skyovergangen. For at gøre migreringen så enkel som muligt med minimal chance for fejl anbefaler Cisco, at du migrerer fysiske websteder eller afdelinger på samme tid. Du kan dog blive bedt om at migrere brugere i batcher på grund af funktionsafhængigheder. Se afsnittet Over før brugere i grupper for at få flere oplysninger.
Alle understøttede telefoner, som du har brug for at skifte fra, skal konfigureres som bruger eller arbejdsområde, og den fysiske telefon skal omkonfigureres for at registrere dig hos . Derudover har telefonerne i 7800- og 8800-serien brug for deres firmware opgraderet fra Enterprise- firmware til Multiplatform Phone (MPP) firmware. Denne proces omfatter indlæsning af overgangs firmware før indlæsning af den MPP-firmware, der kræves til registrering. Det kræver også den relevante migrationslicens. Cisco har forbedret denne proces i løbet af de sidste par år for at gøre det lettere for dig at opgradere dine Enterprise-firmwaretel efoner til MPP-firmware. Du kan finde flere oplysninger om trinene til at fuldføre firmwareopgraderingen i Konvertere IP-telefoner i Cisco 7800- og 8800-serien mellem Enterprise- og MP P- firmware.
Ud over de trin, der er beskrevet i denne artikel, har du et indbygget værktøj, Overfør din telefon til Webex Calling, som du kan bruge til at hjælpe med at migrere dine 7800- og 8800-telefoner fra Enterprise til MPP-firmware. Dette værktøj giver dig også mulighed for at tilføje telefonerne til og tildele dem til de relevante brugere eller arbejdsområder. Du kan finde flere oplysninger om værktøjsbrug under Overfør din telefon.
For telefoner i 9800-serien, der er registreret med ovenstående krav til firmwareoverførsel, gælder ikke. Disse telefoner kører PhoneOS, som understøttes af både og. For at overføre disse telefoner til skal du tilføje dem tilWebex Calling, tildele dem til en bruger eller et arbejdsområde og derefter fabriksindstille telefonerne. PhoneOS-opstartssekvens til registrering Figur nedenfor viser PhoneOS-opstartssekvensen, og hvordan telefonen vil registrere sig, når den er blevet tilføjet til, selvom telefonen stadig er klargjort og/eller DHCP-indstillinger (Eksempel - 150) er i brug.
understøtter fabriksindstilling af PhoneOS-enheder for at tillade Zero-Touch onboarding til. administratorer kan eksternt fabriksindstille 9800- og 8875-telefonerne via CUCM-administrationssi derne, hvilket eliminerer behovet for fysisk adgang til telefonerne, der skal indbygges telefonerne til. Denne funktion understøttes med enhedspakkerne fra 9. september 2025:
-
CUCM v15 - Unified Communications Manager version 15
-
CUCM v14 - Unified Communications Manager version 14.
For mere information om registreringsprocessen for 9800-serien, se Registrerings proces.
Ud over Cisco IP-telefonerne kan levering af andre enheder såsom analoge telefon adaptere (ATA), trådløse (Wifi, DECT) telefoner, videoenheder, stemmegateways og tredjepart senheder og telefoner være påkrævet. Mange af disse enheder har ikke en firmwareopgraderingssti som IP-telefonerne til at overføre dem fra virksomhedsfirmware til cloud- firmware. Derfor klargør du hver af disse enheder i Control Hub. Nogle af disse kan ikke overføres til, og den tilsvarende model skal erstatte den (f.eks. ATA 191/192) og andre vil kræve manuel rekonfiguration og/eller softwareændringer.
- Stemmegateways — Hvis du vil migrere din lokale gateway, skal du se Over føre lokal gateway.
-
Analog telefonadapter (ATA) - For at komme i gang med din Cisco ATA 191 og 192, se Cisco ATA.
-
Trådløs WiFi-telefon - Se Integrere trådløs Webex-telefon for at integrere trådløs telefon 840 og 860.
-
Trådløse DECT-telefoner - Se Cisco IP DECT 6800-serien for at komme i gang med din nye Cisco IP DECT 6800-serie.
Hvis du vil oprette og administrere digitalt DECT-netværk i Control Hub, skal du se Administrer DEC T-netværk
Du kan finde flere oplysninger om Cisco IP DECT 6800 i Installationsvejledning
-
Tred je partsenheder og -telefoner - Arbejd med tredje part sleverandører om enheds-/telefonkrav og processen til at migrere eller erstatte dem til support.
Konfigurer funktioner
Alle opkaldsfunktioner, der kræves, skal klarlægges før eller under overgangen. Som beskrevet i afsnittet Over før brugere i batcher skal opkaldsfunktionerne konfigureres og overføres, når de brugere, der bruger dem, overføres.
Du kan finde flere oplysninger om, hvordan du konfigurerer hver af funktionerne, i de tilsvarende artikler om konfigurationshjælp.
-
Opkaldspark - Se Opkaldspark for at administrere op kald sparkering
-
Afhentning af opkald — Se Afhentning af opkald, hvis du vil konfigurere gruppen for afhentning af opkald
-
Opkaldskøer - Hvis du vil konfigurere opkaldskø, skal du se Op kald skø
-
Jagtgrupper — Se Administrer jagtgruppe for at administrere jagt grupper
-
Driftstilstande - Hvis du vil foretage opkaldsruting baseret på driftstilstande, skal du se Rute opkald baseret på driftstilstande
-
Personsøgningsgrupper — Hvis du vil konfigurere en personsøgningsgruppe, skal du se Konfigurere en personsøgningsgruppe
-
Optagelser - Hvis du vil administrere opkaldsoptagelse for, skal du se Administrer optagelser
-
Enkeltnummerrækkevidde - Hvis du vil konfigurere rækkevidde af et enkelt nummer (kontor hvor som helst), skal du se Konfigurere enkeltnummer
Accepttest
Accepttest sikrer, at det migrerede miljø opfylder funktionskravene, fungerer som forventet og leverer en problemfri brugeroplevelse på tværs af alle kommunikationsarbejdsgange. Denne validerings proces er mangefacetteret og dækker alt fra brugerklargøring og nummertildelinger til den operationelle ydeevne af avancerede opkaldsfunktioner.
Dette afsnit indeholder eksempler og fremhæver nøgleaspekter, der skal overvej es under accepttest; det er dog ikke beregnet til at fungere som en udtømmende eller omfattende tjekliste.
Brugerklargøring og nummertildeling
Et grundlæggende aspekt af accepttest involverer at verificere, at alle brugere er klargjort nøjagtigt og fuldstændigt indeni. Dette kræver en grundig sammenligning mellem source () -mappen og den nyoprettede brugerbase for at sikre, at alle brugerkonti sammen med tilknyttede attributter såsom ud videlsesnumre og DID-tildelinger (Direct Inward Opal) er blevet overført korrekt. Fuldstændighed af klargøring er afgørende ikke kun for funktionsdygtigheden på den første dag, men også for løbende administration og support.
Validering af nummertildeling omfatter bekræftelse af, at hver bruger er tildelt den korrekte udvidelse og det eksterne nummer, og at disse numre dirigeres korrekt i både interne (på nettet) og eksterne (PSTN) opkaldsstrømme. Det er vigtigt at kontrollere eventuelle overlapninger, manglende tildelinger eller fejlkonfigurationer, der kan føre til opkaldsroutingsfejl eller serviceafbrydelser.
PSTN-opkaldsstrømme og præsentation af opkalds-id
En robust accepttestprocedure skal omfatte ende-til-ende- validering af PSTN-opkaldsstrømme. Dette omfatter både indgående og udgående opkaldsscenarier . For indgående PSTN-opkald skal testteamet bekræfte, at opkald leveres til de tilsigtede slutpunkter, uanset om det er individuelle brugere, opkaldskøer, jagtgrupper eller automatiske telefonsvarere. Udgående PSTN-opkald skal foretages med succes, med særlig opmærksomhed på korrekt levering og præsentation af opkalds-ID-oplysninger. Dette indebærer at sikre, at det korrekte opkaldsnavn og nummer vises for eksterne modtagere i overensstemmelse med organisationspolitikker og lovkrav.
Test bør også behandle failover-scenarier, såsom håndtering af utilgæng elige slutpunkter eller netværksforstyrrelser. Dette hjælper med at bekræfte, at reservemekanismer og alternativ routing fungerer korrekt, hvilket opretholder servicekontinuitet og pålidelighed.
Opkaldsstrømme på nettet
Interne eller on-net opkaldsstrømme udgør rygraden i virksomhedskom munikation. Accepttest i dette område bekræfter, at opkald mellem brugere i organisationen dirigeres korrekt, med funktioner som opkaldsoverførsel, hold, videresendelse og konferencer, der fungerer efter hensig ten. Integriteten af opkaldsplaner, forbindelse mellem udvidelse til udvidelse og understøttelse af organisatoriske op kaldspolitikker skal alle bekræftes.
Håndtering af brugeropkald og funktionsvalidering
Et vigtigt aspekt af accepttest involverer validering af, hvordan brugerne håndterer opkald ved hjælp af de og understøttede bordtelefoner. Denne proces fokuserer på at bekræfte, at daglige opkal dsarbejdsgange er intuitive og pålidelige, og at brugerne har problemfri adgang til de kerne funktioner, der er nødvendige for deres roller. Test skal vurdere, hvor let brugerne kan foretage og modtage opkald, administrere hold- og genoptagelsesfunktioner og udføre både blinde og rådgivende overførsler. Det er også vigtigt at kontrollere, at viderestilling af opkald, konferencer og andre avancerede funktioner, såsom parkering og hentning af opkald eller aktivering af forstyrr ikke, er let tilgængelige og fungerer problemfrit.
Oplevelsen bør evalueres for klarhed og lydhørhed under hensyntagen til, hvordan brugerne interagerer med opkaldshistorik, voicemail og integrerede mapper. Der bør lægges yderligere vægt på muligheden for at flytte aktive opkald mellem enheder og til at bruge opkaldskontroller effektivt inden for applikationen eller på fysiske telefoner. Det ultimative mål er at sikre, at slutbrugeroplevelsen er konsekvent, effektiv og fuldt ud understøtter organisationens kommunikationsbehov efter migreringen.
Opkaldskøer: Agent- og vejledererfaring
Opkaldskøer bruges ofte til håndtering af indgående opkaldsscenarier med høj volumen. Accepttest fokuserer her på flere dimensioner. Først skal det verificeres, at opkald distribueres til agenter i henhold til den konfigurerede kølogik, såsom round robin, længste tomgang eller samtidig ring. Præsentationen af opkald i kø på agentdesktops skal undersøges for klarhed og brugervenlighed, hvilket sikrer, at ag enterne effektivt kan acceptere, holde og overføre opkald.
For vejledere bør skrivebordsoplevelsen evalueres for funktioner som realtidsovervågning, opkaldsbarging og analyse eller indsigt i køens ydeevne. Dette omfatter, men er ikke begrænset til, validering af dashboards og rapporteringsværktøjer, der giver handlingsbare data om opkalds distribution, agentaktivitet og kømålinger.
Jagtgrupper: Opkaldsfordeling
Jagtgrupper er en nøglemekanisme til distribution af opkald til foruddefinerede sæt brugere. Accepttest skal bekræfte, at opkald dirigeres til gruppemedlemmer baseret på den konfigurerede jagtalgoritme, og at overløb, videresendelse og no-svar scenarier håndteres i henhold til design. Det er afgørende for driftskonsistens og brugertilfredshed at sikre, at gruppemedlemskab og opkaldsroutingadfærd matcher dem, der tidligere er etableret i.
Automatiske svarbeskeder: Meddelelser og menuhandlinger
Autorespondenter repræsenterer frontlinjen for automatiseret opkaldshåndtering. Test skal dække afspilning af meddelelser, nøjagtigheden af optagede hilsener og korrekt betjening af menutræer. Menu valg skal pålideligt dirigere opkaldere til de relevante afdelinger, enkeltpersoner eller eksterne numre. Test bør også omfatte ugyldige scenarier eller timeout-scenarier for at bekræfte, at opkaldere modtager klar vejledning eller omdirigeres efter hensigten.
Voicemail-betjening
Endelig er voicemail-funktionalitet afgørende for brugeroplevelsen. Accepttests skal kontrollere, at voicemail-bokse er korrekt tildelt og tilgængelige, både inden for organisationen og eksternt. Evnen til at optage, hente og administrere meddelelser skal bekræftes sammen med meddelelseslevering.
Optimer
PSTN-overførsel til Cloud Connect til
Når alle slutpunkter og brugere er migreret til cloud-opkald, Unified CM er det eneste formål at fungere som en transit mellem PSTN-gateways og via Local Gateway. Fjernelse af PSTN-gateways og Local Gateway fra billedet ved at bruge Cloud Connect som PSTN-adgang for alle Webex Calling brugere har flere fordele, herunder omkost ningsreduktion og forbedret pålidelighed. Følg disse trin for at overføre PSTN-adgang i det lokale miljø til Cloud Connect for :
-
Cloud Connect til valg af partner.
Se listen over Cloud Connect for partnere, og vælg blandt de tilgængelige partnere, der er tilgængelige for din organisations placering.
-
Cloud Connect til validering.
Før du skifter PSTN-adgang for lokationer til Cloud Connect, skal forbindelsen til PSTN via den valgte Cloud Connect-partner verificeres og valideres. Til dette formål skal der etableres en testplacering med nogle testbrugere, der er klargjort på den pågældende testplacering. PSTN-adgang til denne test placering indstilles derefter til Cloud Connect-partneren, før PSTN-forbindelsen valideres ved hjælp af testtelefonerne. Efter vellykket validering kan testplaceringen afklar es.
-
Nummerportering.
For at forberede overgangen til Cloud Connect skal der placeres en portordre for alle numre, der aktuelt er tildelt PSTN-trunken, der afsluttes. Alle numre skal overføres til Cloud Connect-partneren. For at opretholde interlokationernes tilgængelighed skal alle numre på alle placeringer portes på samme tid.
-
Skift til Cloud Connect-partner.
På datoen for overgangen skal PSTN-adgang for alle placeringer indstilles til Cloud Connected PSTN-udbyderen, og indgående og udgående forbindelse skal verificeres.
Som diskuteret i PSTN-afsnittet i designkapitlet kan kunder også vælge at flytte deres PSTN-adgang til Cloud Connect til i starten af overgangen ved hjælp af PSTN-trunking til hybrid-implementeringer. Du kan finde flere oplysninger under PSTN-trunking til hybridinstallationer. Webex Calling I dette tilfælde er PSTN-adgang under overgangen via lokal gateway, og efter at alle brugere er flyttet til, er der ikke noget yderligere PSTN-relateret migrationstrin bortset fra nedlæggelse og de lokale gateways.
Optimer infrastrukturen i det lokale miljø
Når alle brugere er blevet overført til, og alle slutpunkter er blevet overført til cloud-registrering (eller er blevet taget ud af drift), skal du opdatere passende infrastruktur i det lokale miljø, nu hvor cloud-opkald er i brug. Opdateringer af infrastrukturen omfatter:
-
Fjern opkaldsstyring og meddelelses DNS SRV poster i det lokale miljø fra DNS-serveren (e) i det lokale miljø, herunder cisco_uds. _tcp. <domain>, cup_login. _tcp. <domain>. Disse SRV-poster er ikke længere nødvendige for opdagelse af klienttjenester.
-
Fjern kantrelaterede DNS SRV poster fra det offentlige DNS-system inklusive collab_edge. _tls. <domain>. Disse SRV-poster er ikke længere nødvendige for klientserviceopdagelse af kant tjenester for samarbejde.
-
Opdater alle relevante DHCP-områder for at fjerne option 66 og mulighed 150 TFTP/boot serveradresser. Disse anvendelsesområder er ikke længere nødvendige for opdagelse og download af konfiguration af slutpunktopkaldskontrol.
-
Opdater/fjern passende opkaldskammerater i Lokal gateway/kube, der dirigerer opkald til og fra. Unified CM Disse opkaldsmodparter er ikke længere nødvendige for opkaldsrouting i det lokale miljø.
-
Slet eller fjern alle virtuelle maskiner og/eller servere i klyngeknudepunkter. Genanvend beregningsressourcer og hardware efter behov. Disse ressourcer er ikke længere nødvendige til opkaldskontrol og kanttjenester.
-
Slet eller fjern alle virtuelle klyngeknudemaskiner og/eller servere. Genanvend beregningsressourcer og hardware efter behov. Disse ressourcer er ikke længere nødvendige for telefonsvarer og samlede meddel elsestjenester.
-
Oprydning: Efter migrering af PSTN-adgang til Cloud Connected PSTN kan PSTN-trunker, PSTN-gateways og Local Gateway deaktiveres.
-
For enhver eksisterende E911-løsning i det lokale miljø skal du slette alle placeringer eller numre, der er migreret til, og når den fulde overgang er fuldført, fjerne virtuelle applikationsmaskiner eller -servere. Genanvend beregningsressourcer og hardware efter behov. Disse ressourcer er ikke længere nødvendige til nødopkald og lokaliseringstjenester.
-
DN'er, der tilhører migrerede brugere, skal placeres i en skjult partition for at undgå fejl i opkaldsrouting og for at sikre, at alle CSS'er har prioriteret adgang til skystien for de samme DN'er.
-
Opdater den fysiske afsendelsesplacering og netværkselementet i horisontmobilitet, når der sker ændringer. Almindelige aktiviteter, der kræver opdateringer, er:
-
Udskiftning af netværksafbryder
-
Udskiftning af trådløst adgangspunkt
-
Ændringer i DHCP-omfang
-
Fysiske ændringer inde i bygningen (hvis de løses til kubikal/kontor)
-
Fysisk udvidelse eller sammentrækning af kontorlokaler inde i en bygning.
-
Brug analyser og fejlfinding
giver omfattende analyse- og fejlfindingsfunktioner, der hjælper dig med at visualisere og spore din implementering. Disse dækker mediekvalitet, detaljeret opkaldshistorik, opkaldskø, jagt gruppe og automatisk ledsager analyse. Et eksempel på mediekvalitetsanalyse er vist i figur mediekvalitetsanalyse.
Under fejlfinding kan hvert opkald, der foretages ved hjælp af, ses med detaljerede oplysninger om vigtige mediekvalitet og signalrelaterede problemer for at hjælpe med at identificere medieproblemer såvel som mislykkede opkald, som vist i fejlfinding af medi ekvalitet i figuren.
Fejlfinding kan også integreres med andre Cisco-produkter som ThousandEyes og Meraki- switche for at give en endnu rigere integreret oplevelse i Control Hub. Du kan finde flere oplysninger om brug af Webex Callinganalyse og fejlfinding under Fej lfinding af Webex Calling opkald i Control Hub.
Før du begynder
Denne vejledning er beregnet til teams eller enkeltpersoner med erfaring med at konfigurere og administrere Cisco Unified Communications Manager (Unified CM) og Cisco-slutpunkter, herunder IP-desktelefoner, videoenheder og Jabber-softwareklienter. I hele dette dokument er der links til produkt- og supportdokumentation, der kan hjælpe.
Dette dokument fokuserer kun på overgange fra Unified CM til Webex Calling multi-tenant. Udtrykket Webex Callingi dette dokument henviser altid til Webex Calling multi-tenant.
Før du begynder migreringen fra Unified CM tilWebex Calling, er det bydende nødvendigt at have en omfattende forståelse af Webex Calling løsningen og dens respektive komponenter. En vellykket migrering kræver kendskab til Webex Calling arkitek turen, servicemodellerne, implementeringsmulighederne og tilknyttede funktioner for korrekt at kortlægge eksisterende Unified CM arbejdsbelastninger og designe en effektiv overgangsplan.
En grundig forståelse af følgende Webex Calling komponenter er afgørende for at informere om en effektiv overgangsstrategi og operationel beredskab.
-
Kontrolhub
-
Klargøring af mapper og brugere
-
Webex Callingplatform
-
Understøttede opkaldsendepunkter
-
PSTN-tilslutningsmuligheder
-
Webex Callingopkaldsplan og nummerstyring
-
Sikkerheds- og overholdelsesfunktioner.
Du kan finde flere oplysninger i Cisco Preferred Architecture forWebex Calling.
Denne vejledning fremhæver værktøjer og processer, der skal bruges gennem hele overgangens livscyklus. En overgang fra opkald i det lokale miljø til en ny cloud-opkaldsplatform kan Webex Calling dog være en betydelig indsats med potentielle forretningsmæssige, tekniske og komplekse udfordringer. Unified CM For at hjælpe med at overvinde disse udfordringer har Cisco et par forskellige muligheder til rådighed for at hjælpe dig med din rejse. Det er vigtigt at gennemgå oplysningerne i Enterprise Cloud-opkald - Overførsel af opkald og forstå hver mulighed, og hvordan hver enkelt mulighed muligvis kan hjælpe dig med din egen overførsel.
-
Webex-migreringsværktøjer: selvbetjente, gratis værktøjer indbygget i Control Hub for at strømline din overgang til Webex Calling
-
Certificerede overførselsudbydere: Cisco-validerede software- og værktøjsudbydere, der har udviklet migreringsløsninger til at hjælpe Webex-partnere og kunder med komplekse og store migreringer. Disse løsninger kan hjælpe med at forenkle, styre og fremskynde overgangen til Webex Calling
-
Webex Setup Assist: en Cisco-ledet migreringstjeneste, der guider kunder og partnere gennem udrulningen Webex Calling og konfigurationen, som er nødvendig for at kunne migrere Unified CM brugere og tjenester til. Webex Calling
Oversigt
Med væksten i cloud-leverede samarbejdstjenester søger flere kunder at flytte deres eksisterende samarbejdsarbejdsbelastninger til skyen i betragtning af løf terne om reducerede samlede ejeromkostninger, forenklet administration, kontinuerlig levering af funktioner, øget skalering og overlegen pålidelighed, der er iboende i skybaserede tjenester. Når kunderne ønsker at foretage overgangen fra lokale samarbejdstjenester til cloud-samarbejdstjenester, er det vigtigt for dem at forstå, hvad overgangen indebærer, og de trin, der kræves for at gennemføre overgangen.
Formålet med dette dokument er at give installationsvejledning til kunder, der specifikt ønsker at skifte fra det lokale miljø Unified CM til Webex Calling i skyen. Denne installationsvejledning antager, at læseren har en grundlæggende forståelse af opkald sovergangen mellem Unified CM ogWebex Calling, herunder hvilke ændringer, der foretages, når denne overgang foretages, og hvad forskellene er, når opkaldsarbejdsbyrden flyttes fra det lokale miljø til skyen. Før du fortsætter, skal du sikre dig, at du har gennemgået og er fortrolig med de oplysninger, der er tilgængelige på overgangskortet. Dette overgangskortdokument indeholder oplysninger om ændringerne og forskellene i denne overgang.
Som vist i figur Samarbejdsarkitektur i det lokale miljø: opkaldsstyring og fjernad gang omfatter en typisk lokal implementering forskellige samarbejdsinfrastruktur komponenter på netværket, en opkaldsstyringsplatform, en kantplatform, hardware- og software slutpunkter og i nogle tilfælde endda konference- og planlægningsplatforme. I Cisco- arkitekturen vil dette omfatte Unified CM opkaldskontrol, Expressway til fjernadgang og business-to-business (B2B) edge-tjenester, Cisco Meeting Server/ Cisco Meeting Management til lokale konferencer, Unity Connection til talemeddelelser og brugerrettet hardware (Cisco IP-telefoner, Cisco Desk- og Room-video systemer) og software () IP-baserede slutpunkter. Cisco Jabber Disse komponenter kan variere lidt i nogle miljøer, men dette er udgangspunktet for overgangen beskrevet i resten af dette dokument.
Arkitekturen vist i figur Samarbejdsarkitektur i det lokale miljø: opkaldsstyring og fjernadgang er baseret på Preferred Architecture (PA) for Cisco Collaboration Enterprise On-Premises Imployments. Du kan finde flere oplysninger om Enterprise On-premise under Ciscos foretrukne samarbejdsarkitekturer.
Før: Tabellen med opkaldsinfrastrukturkomponenter i det lokale miljø viser nøgleelem enterne i arkitekturen Webex Calling i det lokale miljø, før overgangen til skyen.
| Produkt | Beskrivelse |
|---|---|
| Unified CM | Lokal opkaldsstyring, der leverer enhedsregistrering og opkaldsroutingtjenester |
| Cisco Expressway-C/E | Edge-infrastruktur, der leverer mobil- og Remote Access (MRA) og business-to-business (B2B) funktionalitet, der gør det muligt for eksterne slutpunkter at oprette forbindelse sikkert uden for organisationen . Expressway implementeres parvis for at give firewall-kryd sning til eksterne slutpunkter. |
| Cisco mødeserver (CMS), Cisco mødestyring (CMM) og Cisco TelePresence Management Suite (TMS) | Lokal tale-, video- og webkonferenceinfrastruktur, der leverer multipunktmøder, mødestyring og planlægningsfunktioner. [Valgfrit] |
| Cisco Unity Connection | Lokal stemmemeddelelsesplatform, der giver mulighed for telefonsvarer og samlede meddelelsesfunktioner. [Valgfrit] |
| Cisco Desk, Cisco Room, Cisco Board, Cisco IP-telefoner og Cisco Jabber | IP-baserede enheder, der er registreret til Unified CM og giver mulighed for tale- og videoopkald |
Som illustreret i Figur Overgangsbeslutning: Opkald i det lokale miljø Webex Calling kan kunder, der har en lokal opkaldskontrol med Unified CM og skrivebords- og video-IP-slutpunkter, vælge mellem at skifte arkitekturen til en cloud-arkitektur. Webex Calling
Beslutningen skal træffes ud fra kundens funktionalitetskrav. Kunder, der har følgende krav, bør overveje nøje, før de træffer denne beslutning, og kan i sidste ende beslutte at beholde opkaldskontrol i det lokale miljø:
- Telefonmodeller understøttes ikke af Webex Calling
- Komplekse eller talrige integrationer med andre lokale systemer eller løsninger, især hvor Webex Calling det er vanskeligt at replikere disse integrationer med, eller der ikke findes tilsvarende alternative løsninger
- Kompleks opkaldsplan, meget detaljerede serviceklasser eller begge dele
- Begrænset, begrænset eller upålidelig internetadgang
- Strenge databeskyttelses- og ejerskabspolitikker
- Overholdelseskrav for medieoptagelse og -lagring i det lokale miljø eller i landet
- Tredjepartsintegrationer uden levedygtig alternativ integration Webex Calling
- Kontaktcenterintegrationer, hvor kontaktcenterinteren endnu ikke flytter til sky en.
Dette dokument fokuserer på kunder med udrul Unified CM ninger af opkaldskontrol, der ønsker at forstå de generelle trin, overvejelser og krav til aktivering af Webex Calling udrulning som beskrevet i næste afsnit.
Kernekomponenter
Målarkitekturen for denne migrering omfatter flere nye komponenter. Dette omfatter Webex Calling tjenesten til skybaseret opkald, Webex App, Cisco Directory Connector til identitetsintegration og Local Gateway (LGW) til PSTN- adgang samt integration af opkald i det lokale miljø til skyen. Cisco-opkaldsplaner eller Cloud Connec ted PSTN (CCP) faciliteret af en Cloud Connect for Webex Calling partner er yderligere muligheder for PSTN-adgang.
Som vist i Figur Efter: Webex Calling Arkitektur føjes de nye komponenter (Webex Calling, Katalogforbindelse, Lokal gateway og Overlevelses-gateway) til den eksisterende installation i det lokale miljø.
Efter: Tabellen over cloud-opkaldsinfrastrukturkomponenter viser de nye elementer i arkitekturen efter overgangen til Webex.
| Produkt | Beskrivelse |
|---|---|
| Webex Calling | Cloud-baseret opkaldstjeneste leveret fra Webex-platformen og leverer slutpunktregistrering og opkaldsrouting |
| Cisco Directory-stik | Windows-program, der kører på en Windows-domænemaskine, der leverer identitet
ssynkronisering mellem virksomheden i det lokale miljø Active Directory og identitetsl
agringen i Webex-organisationen. For kunder, der flytter fra det lokale miljø Active Directory til Entra ID, bruger identitetsintegrationen med Webex i stedet for Cisco Directory Connector appen Entra ID Wizard. |
| Lokal gateway | En lokal gateway fungerer som en bro mellem en kundes samlede kommunikationsnetværk i det lokale miljø og Webex Calling skyen. Det kan implementeres lokalt eller hostes af en partner, hvilket giver PSTN- adgang til cloud-registrerede slutpunkter samt opkaldsintegration mellem registrerede og cloud- Unified CM registrerede slutpunkter. Cisco IOS-XE Integrated Services Router (ISR 1100- og 4000-serien), Cisco Catalyst 8200/8300-serien, Cisco Catalyst 8000V Edge- software og forskellige certificerede tredjeparts Session Border Controllers (SBC'er) kan bruges som LGW til en trinvis migrationsmetode. |
| Gateway til overlevelsesevne | Survivability Gateway (SGW) er en lokal IOS-XE-baseret gateway, der leverer fallback-opkaldstjenester til slutpunkter på stedet Webex Calling under netværksafbrydelser. |
| Cisco-opkaldsplan, Cloud Connect til Webex Calling | Cisco Calling Plan og Cloud Connect for Webex Calling er skybaserede muligheder for PSTN-adgang til Webex Calling slutpunkter. PSTN-adgang lettes af en PSTN-udbyder i skyen og kræver intet udstyr i det lokale miljø. |
| Webex-appen | Klientapplikation, der kører på desktop OS (Windows, Mac) eller mobilt OS (Android, iOS) og registreres direkte på Webex Calling platformen for opkaldsfunktionalitet. |
PPDIO procesoversigt
PPDIO- processen står for Forbered, Planlæg, Design, Implementér og Optimér. Det er en struktureret Cisco-metode, der guider projekter fra indledende vurdering til kontinuerlig forbedring, hvilket sikrer effektive og vellykkede implementeringer eller migreringer.
Generel beskrivelse af PPDIO
-
Forbered dig: Vurder det nuværende miljø, indsaml krav, og tilpas interessenter for at etablere et solidt fundament.
-
Plan: Udvikle detaljerede projektplaner, herunder tidslinjer, ressourcer og risikobegrænsende strategier.
-
Design: Arkitekt målløsningen skræddersyet til forretningsmæssige og tekniske behov.
-
Implementere: Udfør implementeringen eller migreringen i henhold til designet, validering af funktionalitet og ydeevne.
-
Optimer: Forbedre løsningen løbende efter implementeringen ved at overvåge ydeevne, forfine konfigurationer og udnytte automatiserings- og integrationsværktøjer.
Brug af PPDIO Unified CM til Webex Calling migreringsprojekter
Ved overgangen fra Unified CM til Webex Calling giver PPDIO-processen en klar køreplan for at sikre en smidig og effektiv overgang:
Forbered
-
Vurdere det eksisterende Unified CM miljø og migrationsberedskab
-
Indsamle detaljerede data om brugere, enheder, netværk og afhængigheder
-
Indsamle placeringsoplysninger, herunder nødberedskabsadresse, antal brugere, internet adgang, PSTN-adgang
-
Identificer risici og definer projektomfang for at tilpasse alle interessenter.
Planlæg
-
Opret en omfattende overførselsplan med batchplaner, ressourcetildelinger og tidslinjer
-
Definer opgaver som enhedens firmwareopgraderinger, licensklarering og bruger onboarding
-
Koordiner migreringsvinduer med Cisco og partnere for at minimere forstyrrelser.
Udformning
-
Kortlæg aktuelle Unified CM konfigurationer, opkaldsplaner og brugerprofiler til Webex Calling ækvivalenter
-
Design Webex Calling miljøet, herunder PSTN-strategi (midlertidig og endelig), placeringer, brugerroller og integrationspunkter som Local Gateway (CUBE) og mappesynkronisering
-
Planlæg for sameksistensscenarier, hvor Unified CM og Webex Calling fungerer samtidigt under migrering.
Implementere
-
Brug Control Hub-migreringsværktøjer sammen med tredjepartsværktøjer til at udføre ændringer i enhedens firmwaretilstand, funktionskonfiguration og brugermigreringer
-
Anvend masseoperationer og klargøring ved hjælp af Webex API'er til at strømline store overførsler og konfigurationer
-
Udfør licensudstedelse, enhedsregistrering og konfigurationsopdateringer
-
Valider overførselssucces gennem test og operationel verifikation.
Optimer
-
Kontinuerlig overvågning af Webex Calling ydeevne og brugeroplevelse
-
Begræns konfigurationer og arbejdsgange baseret på driftsdata og feedback
-
Udnyt automatiserings- og integrationsfunktioner til at forbedre effektiviteten og skalerbarheden
-
Afmontere ældre Unified CM komponenter efter behov og yde løbende støtte til dag-2-operationer.
Denne forbedrede PPDIO-tilgang sikrer en kontrolleret, gennemsigtig og effektiv migration fra Unified CM til ved at udnytte Ciscos værktøjerWebex Calling, API'er og partnerøkosystem til at opretholde forretningskontinuitet og forbedre samarbejdsfunktioner.
PPDIO feedbacksløjfer
Oversigten på højt niveau afbildet i figur iterationer under udførelse af PPDIO illustrerer en enkelt feedback-loop fra optim eringsfasen tilbage til forberedel sesfasen. Dette betyder, at der efter den indledende implementering er en løbende mulighed for løbende forbedringer. Hver optimeringscyklus kan identificere nye krav eller områder til forbedring, som kan løses gennem efterfølgende projekter eller initiativer. Disse individuelle projekter følger til gengæld hver den etablerede PPDIO (Prepare, Plan, Design, Implement, Optimize) livscyklus. Denne iterative tilgang sikrer, at systemet forbliver på linje med udviklende forretningsmål og teknologiske fremskridt, hvilket fremmer en kultur med løbende forfining og tilpasningsevne.
Under udførelsen af PPDIO-processen er det almindeligt, at resultater i de senere faser nødvendiggør revurdering og potentielt revision af beslutninger truffet i tidligere faser. For eksempel kan problemer, der opstår i gennemførelsesfasen, såsom identifikation af uklar heder i designet eller manglende detaljer, afsløre, at visse aspekter ikke blev behandlet fuldt ud i designfasen. I sådanne tilfælde bliver det nødvendigt at gentage tilbage til den relevante tidligere fase for at løse disse problemer, før du fortsætter. Denne iterative feedback mekanisme, som illustreret i figur Unified CMassisteret PPDIO-proces, sikrer, at løsningen er grundigt valideret og raffineret, hvilket i sidste ende bidrager til en mere robust og effektiv implementering.
Når der foretages en overgang fra Unified CM tilWebex Calling, kan hver fase af PPDIO-processen drage stor fordel af information indsamlet fra det eksisterende Unified CM miljø. For eksempel kan omfattende opgørelser over brugere, telefonnumre, opkalds funktioner og opkaldsplankomponenter ekstraheres fra den aktuelle Unified CM konfiguration. Disse data supplerer oplysninger leveret direkte af interessenter og hjælper med at strømline planlægnings- og designaktiviteter. Udnyttelse af passende værktøjer til at automatisere data ekstraktion og analyse forbedrer ikke kun nøjagtigheden, men fremskynder også den overordnede proces. Ved at udnytte indsigt fra den eksisterende implementering Webex Calling kan overgangen til udføres mere effektivt end en traditionel greenfield-implementering, mens den stadig over holder den strukturerede PPDIO-metode. Denne proces er illustreret i figur Unified CMassisteret PPDIO-proces.
Migrationsmetode
Når du planlægger din overgang fra det lokale miljø Unified CM til det lokale Webex Calling miljø, skal du bestemme, hvordan du vil forholde dig til denne rejse. Først skal du beslutte, om migr eringen vil være en flash-cut (alt på én gang) eller en trinvis tilgang (migrere grupper af brugere/enheder over en længere periode).
Hvis du foretager en flash-cut- overførsel, flytter alle dine brugere og enheder hurtigst muligt. Med denne metode flytter du alle brugere og enheder fra det lokale miljø Unified CM til Webex Calling på samme tid. I det væsentlige er det et enkelt migreringsvindue for alle brugere og enheder. Når denne migrering er afsluttet, vil alle dine brugere og enheder være på Webex Calling platformen, og al din Unified CM infrastruktur kan tages ud af drift. Mange organisationer kan dog ikke bruge denne tilgang på grund af omfanget og størrelsen af deres opkaldsinstallation.
Den anden tilgang er en tr invis migration. De fleste organisationer vil bruge denne tilgang, da den giver bedre kontrol, styring og skalering med migreringen. Det er også bedre egnet til større UC-implementeringer og/eller implementeringer på tværs af flere regioner. Derfor fokuserer dette dokument på den trin vise tilgang med to trin i overgangen.
Som vist i nedenstående figur Trinv is opkaldsovergang: Hybrid og cloud resulterer den første overgangsfase (fase 1) i en sameksistensimplementering med dobbeltopkaldsmiljøer. I denne fase overføres nogle brugere, enheder og bløde klienter til, Webex Calling mens andre stadig er på opkaldskontrollen i det lokale miljøUnified CM. Den sidste overgangsfase (fase 2) resulterer i et rent cloud-opkald smiljø, hvor alle brugere, enheder og bløde klienter er blevet fuldt overgået til Webex Calling platformen.
Hvor lang tid det tager en organisation at skifte helt til cloud-opkald varierer afhængigt af dens aktuelle implementering. I nogle tilfælde kan en organisation foretage den indledende overgang og forblive i sameksistensfasen med dobbelt opkaldskontrol (fase 1) i en længere periode (måneder eller endda år), mens en organisation i andre tilfælde kan overgå fuldt ud til Webex Calling (fase 2) i en meget kort periode (uger eller måneder). Dette dokument er beregnet til at dække begge faser (fase 1 - sameksistens og fase 2 - fuldstændig overgang).
Det er muligt, at nogle organisationer kan opretholde en sameksistens med dobbelt opkaldskon trol på ubestemt tid uden planer om nogensinde at overgå fuldt ud til cloud-opkald.
Den anden overvejelse er, hvordan du overfører brugere, enheder og bløde klienter fra den lokale op kaldskontrol til cloud-opkaldskontrollen. Den anbefalede tilgang er en 3-trins overgang. Figuren Anbefalet 3-faseovergang nedenfor opdeler denne tilgang i de 3 faser.
Før migrering: Denne fase fokuserer på at gøre både Webex og Unified CM miljøer klar til migreringen. Dette handler ikke om at kalde specifik planlægning eller konfigurationer og fokuserer på at gennemføre aktiviteter, der kan udføres nu og før et Webex Calling migrationsprojekt starter. Målet er at bygge fundamentet for, at de to miljøer kan forberede sig på migrationen.
Migrationsforberedelse: Denne fase begynder indsatsen for at forberede migreringen til Webex Calling. Her skal forretningsmæssige og tekniske krav gennemgås og opdateres. Gør ikke bare et løft og skift af det, der i øjeblikket implementeres med, Unified CM og omdefiner i stedet de forretningsmæssige og tekniske krav, som din virksomhed har brug for i dag og i fremtiden ved at udnytte kraften i. Webex Calling Derudover er dette den fase, hvor du vil fuldføre dit design, konfigurations planlægning og migrationsplanlægning/tidsplan.
Migrering (udrulning og nedlæggelse): Denne fase er, hvor den faktiske migrering af brugere, enheder, telefonnumre og bløde klienter finder sted. Som diskuteret ovenfor kan denne fase afsluttes for alle på én gang (flash-cut) eller over flere ændringsvinduer (fas e-cut). Slutbrugerens adoptionsplaner, uddannelse og kommunikation er afgørende, så dine brugere er opmærksomme på ændringerne, hvordan de bruger den nye opkaldsplatform, og ved, hvornår æn dringen vil ske. Det sidste trin er at deaktivere al den lokale UC-infrastruktur , der ikke længere bruges.
Fasen før migrering indeholder aktiviteter (påkrævet, anbefalet og valgfrit), som du kan begynde at arbejde på med det samme. Det anbefales at gennemføre disse før snarere end senere og helst inden dit projekt begynder. Nogle af aktiviteterne kan tage længere tid at gennemføre, og at starte dem tidligere vil hjælpe med at strømline dit faktiske migreringsprojekt.
Figuren Præmigrationsaktiviteter nedenfor fremhæver fem specifikke kategorier af aktiviteter, der er relateret til en Webex Calling migration.
Forbered
Forretningsmæssige og tekniske krav
Når du planlægger en migrering fra til, er det afgørende at indsamle både tekniske og forretningsmæssige krav grundigt i planlæg ningsfasen. Dette trin sikrer, at migrering stemmer overens med organisationens operationelle mål og tekniske muligheder, hvilket minimerer risici og forstyrrelser.
Hvorfor indsamling af krav er vigtigt:
-
Justerer forretningsmæssige mål: Forståelse af forretningsbehov hjælper med at skræddersy migreringen til at understøtte vigtige arbejdsgange, brugeroplevelse og vækstplaner.
-
Sikrer teknisk kompatibilitet: Identificering af tekniske krav tidligt forhindrer integrationsproblemer med eksisterende infrastruktur, netværk og slutpunkter.
-
Letter ressourceplanlægning: Klare krav hjælper med at estimere tidslinjer, omkostninger og nødvendige ressourcer nøjagtigt.
-
Reducerer risici: Tidlig opdagelse af potentielle udfordringer giver mulighed for proaktive løsninger, hvilket reducerer nedetid og serviceafbrydelser.
Forretningskrav
Typiske forretningskrav omfatter:
-
Antal brugere og placeringer, der skal overføres
-
Ønskede funktioner og tjenester (eksempel opkaldsrouting, voicemail, konferencer, automatiske telefonsvarere, op kaldskøer)
-
Overholdelses- og sikkerhedspolitikker
-
Budgetbegrænsninger og omkostningsforventninger
-
Brugeruddannelse og supportbehov
-
Overvejelser om migrationstidslinje og forretningskontinuitet.
Indsamling af ønskede funktioner og tjenester er et kritisk skridt for at sikre, at det nye system opfylder forretningsbehov. Når du samler disse krav, er det vigtigt ikke kun at overveje, hvad der aktuelt er konfigureret i, men forsøge at indsamle de faktiske krav fra de forretningsenheder, der skal bruge systemet. Ellers er der risiko for, at planen er baseret på langfristede antagelser. Sørg for at evaluere yderligere eller forbedrede funktioner, der er tilgængelige i, som muligvis ikke findes i, såsom skybaserede opkald, avancerede opkaldskøer, , og. Dette hjælper med at udnytte de fulde fordele ved skyplatformen.
Når du evaluerer den aktuelle konfiguration i, er det vigtigt at erkende, at ikke alle eksisterende indstillinger muligvis forbliver nødvendige på grund af skiftende krav gennem hele systemets livscyklus. Fokus bør være på kun at identificere og bevare de konfigurationer, der stemmer overens med de nuværende og fremtidige behov for implementeringen.
Fokuser mere på det, du har brug for, end hvad du har.
Overholdelses- og sikkerhedspoliti kker er vigtige overvejelser under overfør slen fra Webex Calling til for at sikre, at det nye skybaserede kommunikationssystem overholder juridiske, lov givningsmæssige og organisatoriske standarder.
-
Overholdelse af lovbestemmelser: Organisationer skal kontrollere, at de overholder branchespecifikke regler såsom GDPR, HIPAA eller SOX, og imødekommer krav til databeskyttelse, opbevaring og håndtering samt landespecifikke mandater relateret til dataopholdssted, bompengeomgåelse og medielokalitet.
-
Datasikkerhed: Sikring af, at tale- og signaldata krypteres både under transit og i hvile for at beskytte mod aflytning eller uautoriseret adgang.
-
Adgangskontrol: Definere og håndhæve brugergodkendelse, autorisation og rollebaseret adgang for at forhindre uautoriseret brug af kommunikationsressourcer.
-
Revision og overvågning: Implem entering af logning og overvågningsfunktioner til at spore adgang og brug til overholdelsesrevisioner og undersøgelser af sikkerhedshændelser.
-
Politiktilpasning: Til pasning af migreringen til eksisterende virksomhedssikkerhedspolitikker, herunder slutpunktssikkerhed, netværkssegmentering og hændelsesberedskabsplaner.
-
Leverandørsikkerhedsforsikring: Evaluering af Ciscos sikkerhedscertificeringer og overensstemmelsesattester for at sikre pålidelighed.
Håndtering af disse overholdelses- og sikkerhedspolitikker i planlægningsfasen hjælper med at mindske risici, undgå juridiske sanktioner og bevare integriteten og fortroligheden af kommunikationen under og efter migreringen.
Brugeruddannelse og supportbehov er vigtige komponenter under migreringen fra til for at sikre en gnidningsløs overgang og brugeradoption. De vigtigste overvejelser omfatter:
-
Træningsprogrammer: Ud vikle skræddersyede træningssessioner til forskellige brugergrupper (slutbrugere, administratorer, helpdesk-personale) for at gøre dem bekendt med funktioner, brugergrænseflader og nye arbejdsgange.
-
Dokumentation: Giv klare, tilgængelige brugervejledninger, ofte stillede spørgsmål og hurtigt referenc emateriale, herunder Nyheder og Forskel lige ressourcer og trinvise før- og efter -vejledninger (i video- eller hurtigguideformat) for at støtte brugerne, når de tilpasser sig den opdaterede oplevelse efter migrationen.
-
Ændringsstyring: Kommuniker ændringer proaktivt for at styre brugernes forventninger og reducere modstanden.
-
Supportstruktur: Opret et dedikeret supportteam eller en eskaleringssti for at løse brugerproblemer hurtigt under og efter migreringen.
-
Løbende uddannelse: Planlæg løbende uddannelsesopdateringer, når nye funktioner eller opdateringer fri gives i.
-
Feedbackmekanismer: Implementere kanaler, hvor brugerne kan rapportere problemer og give feedback for at forbedre trænings- og supportprocesser.
Håndtering af disse trænings- og supportbehov i planlægningsfasen hjælper med at minimere forstyrrelser, forbedrer brugernes tillid, og maksimerer fordelene ved at migrere til.
Tekniske krav
Flere vigtige tekniske krav skal indsamles og dokumenteres for en vellykket over gang fra til, herunder oplysninger om:
-
Netværksberedskab og båndbreddekapacitet
En omfattende netværksvurdering er afgørende for at sikre, at din eksisterende infrastruktur kan understøtte det nye Webex Calling miljø. Dette omfatter:
-
Båndbreddeanalyse: Evaluering af nuværende og projiceret båndbreddebrug til håndtering af tale-, video- og datatrafik uden overbelastning.
-
Quality of Service (QoS): Implementering af QoS-politikker for at prioritere taletrafik og minimere ventetid, jitter og pakketab.
-
WAN- og internetforbindelse: Kontrol af, at WAN-links og internet forbindelser opfylder kravene til cloud-baserede opkald, herunder redundans- og failover-funktioner.
-
Firewall- og NAT-konfiguration: Sikring af, at firewall- og NAT-indstillinger tillader påkrævet signalering og medietrafik for.
-
-
Integration med eksisterende system
Problemfri integration med eksisterende forretningssystemer er afgørende for brugeroplevelsen og kontinuiteten i arbejdsgangen:
-
Katalogtjenester: Vur dering af integration med en virksomhedskatalog til automatiseret brugerklargøring og godkendelse.
-
CRM- og forretningsapplikationer: Identificering af integrationspunkter med kunde forholdsstyringssystemer og andre forretningskritiske applikationer.
-
Legacy PBX-samarbejdning: Planlæg ning af sameksistens eller fasede migrations strategier, hvis der forbliver ældre telefonisystemer under overgangen.
-
-
Slutpunktskompatibilitet og klargøring
Alle slutpunkter, herunder bordtelefoner, softphones og mobile enheder, skal evalueres for kompatibilitet:
-
Enhedssupport: Bekræfter, at eksisterende IP-telefoner og enheder understøttes af eller identificerer nødvendige udskiftninger.
-
Klargøringsprocesser: Etabler ing af automatiserede eller strømlinede klargøringsm etoder til effektiv onboarding af slutpunkter.
-
Firmware- og softwareopdateringer: Planlægning af nødvendige opdateringer for at sikre interoperabilitet og sikkerhed.
-
-
Sikkerhedskonfigurationer og krypteringsstandarder
Sikkerhed er altafgørende i cloud-kommunikation:
-
Kryptering: Håndhævelse af ende-til-ende-kryptering til signalering og mediestrømme i overensstemmelse med Ciscos bedste praksis for sikkerhed.
-
Godkendelse og adgangskontrol: Implementering af sikre godkendelses mekanismer (såsom SSO, multifaktorgodkendelse) og granulær brugeradgang skontrol.
-
Overholdelse: Sikring af, at løsningen opfylder relevante lovgivningsmæssige og brancheoverholdelsesstandarder (f.eks. GDPR, HIPAA).
-
Sikkerhedsovervågning: Integration med SIEM-værktøjer og opsætning af advarsler om potentielle sikkerhedshændelser.
-
| Krav | Vigtige overvejelser |
|---|---|
| Netværksberedskab og båndbredde | Båndbredde, QoS, WAN/Internet, Firewall/NAT |
| Integration med eksisterende systemer | Vejviser, CRM, PBX, E-mail/kalender |
| Slutpunktskompatibilitet og klargøring | Enhedsunderstøttelse, klargøring, firmwareopdateringer |
| Sikkerhedskonfigurationer og kryptering | Kryptering, godkendelse, overholdelse, sikkerhedsovervågning |
| Brugeruddannelse og forandringsstyring | Træningsprogrammer, dokumentation, forandringskommunikation |
| Nummerportabilitet og opkaldsplan | Nummermigrering/-portering, oversættelse af opkaldsplan |
| Tredjepartsintegrationer | Personsøgning, kontaktcenter, fax, analoge enheder |
Netværksberedskab og krav
Netværksberedskab er afgørende for en vellykket migrering til enhver skybaseret opkaldsløsning som f.eks. Dårlig netværksplanlægning kan føre til forringet opkaldskvalitet, tabte opkald og utilfredse brugere. Kunder skal foretage en netværksvurdering, før de migrerer til. Det anbefales at bekræfte tilgængeligheden af netværksbåndbredde for forventet opkalds volumen, sikre, at kravene til servicekvalitet (QoS) er opfyldt, og forstå de forskellige porte, der skal åbnes i kantfirewallen (e).
Pålidelig netværksforbindelse med tilstrækkelig servicekvalitet (båndbredde, pakketab, RTT) er et grundlæggende krav for at sikre den bedst mulige brugeroplevelse fra ende til ende for alle tale- og videokompatible slutpunkter, klienter og applikationer, der bruger.
Kunder og partnere har adgang til tilslutningsmuligheder ud over OTT-internet (Over-the-Top) , der kan optimere forbindelsen til at inkludere Webex Edge Connect. Du kan finde flere oplysninger om Webex Edge Connect- designdetaljer i Cisco Preferred Architecture for Webex Edge Connect forWebex Meetings, Calling Multi-Tenant og Dedicated Instance.
Kunder kan bruge cScan til netværksvurdering, som giver information om kundens netværkskvalitet, hvor mange opkald der kan etableres, ventetid osv. Du kan finde flere oplysninger om cScan-værktøjet under Brug cScan til at teste Webex Calling netvær kskvaliteten.
For at sikre, at netværket er klar til migrering til, skal du overveje følgende tjekliste:
-
Båndbredde planlægning
Beregn samtidige opkald pr. websted for at sikre, at du har tilstrækkelig opstrøms- og downstream-båndbredde og medtag plads til anden forretningskritisk trafik og fremtidig vækst.
Tabellen for beregning af båndbredde for op kaldstype viser de tilgængelige opkaldstyper med en implementering sammen med den codec og den maksimale båndbredde, der kræves for hver opkaldstype. Webex Calling Som vist i tabellen for beregning af båndbredde for op Webex Calling kaldsty pe, kan den krævede lydopkaldsbåndbredde for hver opkald stype beregnes ved hjælp af følgende generelle formel:
Antal forventede samtidige opkald * Båndbredde pr. opkald baseret på codec = Påkrævet netværkshastighed.
Tabel 2. Webex Callingopkaldstype båndbredde beregninger Opkaldstyper Codec - båndbredde Båndbreddeberegninger /Skrivebordstelefon -> OPUS - 70 kbps Antal samtidige opkald* 70 kbps = Påkrævet netværkshas tighed /Skrivebordstelefon -> Skrivebordstelefon OPUS — 70 kbps Antal samtidige opkald* 70 kbps = Påkrævet netværkshas tighed /Skrivebordstelefon -> PSTN via LGW G.711 — 80 kbps Antal samtidige opkald* 80 kbps = Påkrævet netværkshas tighed /Skrivebordstelefon -> PSTN via Cloud PSTN (f.eks. Cisco-opkaldsplan) G.711 — 80 kbps Antal samtidige opkald* 80 kbps = Påkrævet netværkshas tighed /Skrivebordstelefon -> Enterprise via LGW G.722 — 80 kbps Antal samtidige opkald* 80 kbps = Påkrævet netværkshas tighed /Skrivebordstelefon -> voicemail OPUS — 70 kbps Antal samtidige opkald* 70 kbps = Påkrævet netværkshas tighed Ved at opsummere den samtidige krævede netværkshastighed pr. op kaldstype kan det samlede potentielle båndbreddebehov for et bestemt websted bestemmes.
Alle opkaldsben er altid forankret på adgangsSBC'erne. For at bestemme den nødvendige internetbåndbredde for en given placering skal ikke kun interlokationsopkaldene overvejes , men også intra-lokationsopkald og opkald til og fra en lokal gateway på det pågældende sted. For eksempel vil et intra-site-opkald mellem to MPP-telefoner kræve op til 2 x 70 kbps fuld duplex på stedets internetadgang.
Tabellen med eksempler på Webex Calling båndbreddeberegning viser et eksempel på en komplet båndbred deberegningsøvelse, forudsat at alle enheder er på det samme sted.
Tabel 3. Webex Calling eksempler på beregning af båndbredde Opkaldstyper Antal samtidige opkald Samlet båndbredde Webex-app/skrivebordstelefon → Webex-app 15 2 * 15 * 70 kbps = 2.100 kbps Webex-app/skrivebordstelefon → Skrivebordstelefon 15 2 * 15 * 70 kbps = 2.100 kbps Webex-app/skrivebordstelefon → PSTN via LGW 50 2 * 50 * 80 kbps = 8.000 kbps Webex-app/skrivebordstelefon → PSTN via Cloud Connect til Webex Calling 0 0* 80 Kbps Webex-app/skrivebordstelefon → Enterprise via LGW 15 2 * 15 * 80 kbps = 2.400 kbps Webex-app/skrivebordstelefon → Voicemail Webex Calling 5 5 * 70 kbps = 350 kbps Samlede opkald/Båndbredde 100 opkald 14.950 kbps/14,95 Mbps -
Alle båndbreddeværdier i ovenstående tabeller henviser til IP-båndbredde. Linkbåndbredde er højere afhængigt af WAN-indkapslinger.
-
Båndbredden i ovenstående tabeller er til lydop kald. For båndbredde til videoopkald understøtter Webex App og MPP 8845/65-telefonerne H.264-video med en maksimal opløsning på 720p ved en maksimal båndbredde på 1.500 kbps pr. opkald. Imidlertid vil mængden af båndbredde, der forbruges på et hvilket som helst tidspunkt under opkaldet, svinge baseret på variabel bithastighed, der er forbundet med videok ommunikation.
-
-
Servicekvalitet (QoS)
Implementer QoS-politikker i dit lokale miljø for at prioritere trafik i realtid og sikre, at QoS opretholdes på tværs af switche, routere og firewalls.
-
Mål for latens, jitter og pakketab
Følgende tærskler anbefales for optimal stemmekval itet, når opkald går over-the-top (OTT) og på tværs af internettet :
-
Latens - mindre end 100 ms envejs
-
Jitter - mindre end 10 ms
-
Pakketab - 0,5% eller mindre.
-
-
Firewall og NAT
Sørg for, at firewallen er konfigureret til at tillade trafik som angivet i artiklen, der er tilgængelig under Portreferenceoplysninger for Webex Calling. Tillad desuden adgang til domæner og IP-områder, der er anført i den samme guide, og undgå SIP ALG, da det forstyrrer SIP-signalering. Medietrafik gennem proxyer bør undgås.
-
DNS og NTP
Sørg for korrekt DNS-opløsning af domæner og pålidelige NTP-servere for at synkronisere enhedsur til TLS-certifikatverifikation og logføring.
-
Failover-planlægning
Overvej eksisterende udbyderdataforbindelser (MPLS, SD-WAN osv.), og planlæg generelt direkte internetadgang på hvert sted i din installation. Planlæg redundante internet forbindelser, hvor høj tilgængelighed er påkrævet. Fordi du vil forbruge skybaserede tjenester, er pålidelig internet forbindelse med tilstrækkelig båndbredde et basis krav. Du bør overveje at foretage denne overgang, hvis din organisations lokationers internetforbindelse (er) generelt ikke er pålidelige med lav ventetid og tilstrækkelig op- og downstream-gennemstrømning.
-
Webstedets overlevelsesevne
Webstedsoverlevelsesevne sikrer, at din virksomhed altid er tilgængelig, selvom din netværksforbindelse går i stykker. Site Survivalability bruger en gateway i dit lokale netværk til at levere en reserveopkaldstjeneste til slutpunkter på stedet i situationer, hvor netværksforbindelsen går i stykker. Overvej webstedets overlevelsesevne med en lokal Survivalability Gateway (SGW), hvis forretningskrav kræver kontinuerlig opkald i tilfælde af netværksafbrydelse. For mere information om kontrol af webstedets overlevelsesevne, se Web stedets overlevelsesevne for. Webex Calling
Opsætning af cloud-forbundet UC
Cloud Connected UC (CCUC) er en skybaseret styrings- og analyseløsning designet til at give centraliseret synlighed, administration og indsigt i implementeringer både i det lokale miljø (f.eks.) og cloud (Unified CM). Det fungerer som en bro mellem traditionelle lokale miljøer og Ciscos cloud-tjenester og understøtter organisationer gennem hele migrations rejsen fra til.
Under overgangen til spiller CCUC en afgørende rolle i strømliningen af migreringsprocessen ved at lette ind samlingen af omfattende data fra den eksisterende Unified Communications-implementering. CCUC hjælper med vigtige overgangsopgaver såsom migrering af enheder, funktioner og bruger kontakter, samt automatisering af firmwareopdateringer til understøttede IP-telefoner. Ved at give centraliseret synlighed og styring hjælper CCUC med at sikre en jævnere og mere effektiv migrationsoplevelse.
Cisco anbefaler stærkt, at CCUC implementeres og implementeres tidligt i overgangsprojektet, ideelt før eller under forberedelsesfasen. Dette giver dig den indsigt og de funktioner, der er nødvendige for grundigt at vurdere, opbevare og planlægge efterfølgende migrering saktiviteter og starte din rejse til og fremtidige hybridfunktioner.
Vurdering af det nuværende miljø
En vigtig aktivitet i planlægningen af din overførsel er at vurdere det aktuelle lokale miljø og implementering. Dette giver indsigt i, hvilke potentielle ændringer der kan være nødvendige for en vellykket overgang til. Det giver dig også mulighed for at vurdere nøgleelementerne i platformen i forhold til den eksisterende installation i det lokale miljø. Du kan bruge disse oplysninger til at identificere, hvilke specifikke opgaver der kræves til overgangen, og hvilke ændringer du vil foretage for at opfylde dine forretningsmæssige og tekniske krav og brugssager.
Følgende aspekter er vigtige at gennemgå som en del af denne indsats.
Licensering
Forståelse af den nuværende licensstruktur for den eksisterende implementering er nøglen, når du forbereder dig på at migrere til. Udfør en licensvurdering af følgende områder af din eksisterende Cisco-on-premises løsning.
-
Platformen
Evnen til fuldt ud at formulere, hvad der i øjeblikket er licenseret på din kerneplatform, vil være afgørende, når du arbejder med dit kontoteam eller partner for at bestemme den bedste vej til fleksibel licensering . er licenseret ved hjælp af flex-licensering. Du kan finde flere oplysninger om flexlicensering i Cisco Collaboration flex plan.
-
Brugere og enheder
Identificer, hvilken licenskategori dine eksisterende brugere og enheder kræver. Dette vil blive brugt til at bestemme, hvilken type licens der kræves for brugerne og enhederne. tilbyder flere licenstyper, herunder Professional- og Standard-licenser til brugere og Professional- og fællesområdelicenser til arbejdsområder. Du kan finde flere oplysninger om enhedslicenser i det datablad, der er tilgængeligt på Enhedslicenser.
-
Lokal gateway
Hvis Cisco Unified Border Element (CUBE) er påkrævet for PSTN-adgang til denne overgang, skal CUBE-licensering også overvejes. CUBE-licensovervejelser er dækket senere i dette dokument.
Placeringer/Steder
Antallet og typerne af websteder (store centrale, regionale, filialer osv.) inden for din eksisterende implementering bør overvejes, når du planlægger denne overgang. En fuld forståelse af de eksisterende implementeringssteder vil hjælpe med strategisk planlægning for en vellykket overgang, især når det kommer til at bestemme, hvilke websteder der skal migreres og i hvilken rækkefølge. Forståelse af detaljerede krav til opkaldsplan (nummerering, opkaldsvaner, begrænsningsklasser osv.), webstedsnetværksforbindelse og båndbredde (internet, WAN, LAN) og PSTN-adgang (lokal eller centraliseret, IP eller TDM) for hvert websted vil være afgørende, når der træffes migrationsbeslutninger. Du kan finde flere oplysninger om almindelige implementeringsmodeller og vigtige overvejelser i oplysningerne om implementeringsmodeller for samarbejde, der er tilgængelige i Collaboration SRND.
En anden vigtig implementeringsovervejelser, når du overgår til, er tilgængelighed. har forskellige funktioner, abonnementer og enheder, der er tilgængelige afhængigt af, hvor installationen er placeret. Du kan finde flere oplysninger om geografisk tilgængelighed under Hvor er Webex tilgængelig? .
Endelig er det vigtigt at forstå, hvilken indvirkning overgangen til vil have på andre samarbejdstjenester. Baseret på formålet med dette dokument er den generelle antagelse, at hvis eksisterende samarbejdstjenester uden for opkaldsarbejdsbyr den skal opretholdes, forventes overgang til fase 1-hybrid-implementeringen, der er nævnt ovenfor. Eksempler på samarbejdstjenester, der kan kræve hybrid udrulning, omfatter det lokale kontaktcenter, der endnu ikke er overført til Webex-kontaktcenter, og tætte integrationer i systemer som personsøgningssystemer og fakturering. Du kan finde flere oplysninger om overgangen til yderligere samarbejdsarbejdsbelastninger og -tjenester under Samarbejdsovergange.
Beholdning af eksisterende enheder/klienter
Før overgangen påbegyndes, er det vigtigt at opbevare dine eksisterende hardware- og softwareslutpunkter. Hvis du har en komplet liste over enhedstyper/modeller, hardwareversioner, softclient-OS-typer og mængder, sikrer du, at du i tilstrækkelig grad kan planlægge overgangen til enh ederne og mindske virkningen for de enheder, der ikke kan migreres til cloud-opkald. Opgørelsen skal bruges til at bestemme de enheder, der skal overgås, og de enheder, der skal udskiftes inden overgangen.
Skrivebordstelefoner
Til skrivebordstelefoner med lyd og video understøttes kun skrivebordstelefoner i 6800, 7800, 8800 og 9800-serien. Dette er en undergruppe af de Cisco IP-telefoner, der understøttes med. Der er nogle modeller og versioner af 6800, 7800 og 8800 telefoner, der ikke kan bruges med. Du kan finde flere oplysninger om, hvilke modeller og hardwareversioner der understøttes, under Under støttede enheder til Webex Calling.
Cisco 6800-seriens IP-telefoner kan ikke opgraderes fra Enterprise-firmware til Multiplatform (MPP) firmware, hvilket er påkrævet for. Derfor skal alle 6800-telefoner, der er registreret til kørende virksomhedsfirmware, udskiftes med en 6800 MPP-model eller med en anden understøttet telefonmodel.
Cisco 7800- og 8800-seriens IP-telefoner skal opgraderes til MPP- firmwaren (Multiplatform Phone) før overgang og registrering af dem til. For at finde ud af, hvilke 7800- og 8800-modeller og hardwareversioner, der understøtter MPP-firmwaren, skal du se Konvertere IP-telefoner i Cisco 7800- og 8800-serien mellem Enterprise - og MPP-firmware.
8845, 8865 og 8865NR har nået slutningen af salget og anbefales ikke at migrere til.
Ældre versioner af 8800-seriens telefoner (8811, 8841, 8851, 8851NR, 8861) anbefales ikke at bruge sammen med. Webex Calling Telefoner med hardwareversioner VID 14 eller tidligere registreres med, men kan opleve nogle ydelsesproblemer på grund af hardwaren.
9800-seriens bordtelefoner kører PhoneOS, som understøtter både og registrering. Derfor kan disse telefoner overgås til uden en firmwareopgradering.
Alle andre IP-telefoner skal udskiftes med en 6800, 7800, 8800 eller 9800-serie telefoner, der understøttes af. Webex Calling Du kan finde flere oplysninger om understøttede IP- og skrivebordstelefoner med i artiklen under Under støttede enheder til Webex Calling.
Videoslutpunkter
Personlige og rumvideoslutpunkter, herunder Cisco Board-serien, Room-serien og Desk- serien, kan oprindeligt SIP-registreres til. Alle disse slutpunkter, der skal foretage lyd- og/eller PSTN-opkald, kræver en opkaldslicens:
-
Delte enheder i konferencelokaler, mødelokaler osv. kræver enten en Professional Workspace- eller Workspace-licens.
-
En slutbrugers personlige enhed kræver en professionel licens eller standardlicens.
Bestem, hvor mange videoslutpunkter der er registreret til og bruges til at foretage lydopkald. Det er muligt, at nogle af videoslutpunkterne kun kan bruges til at deltage i møder eller foretage SIP-videoopkald. I begge tilfælde skal slutpunkterne stadig migreres til, før serverne tages ud af drift, men dette vil hjælpe med at bestemme, hvor mange af dem der har brug for en licens for at fortsætte med at foretage telefonopkald.
-
Når videoenheder flyttes fra registrering til, ændres URI'en for disse slutpunkter, da de nu er registreret i skyen.
-
Telefonmodeller 8845, 8865 og 8875 er personlige video telefoner, der understøttes med.
Bløde klienter
Det er den eneste bløde klient, der understøttes af, i modsætning til Unified CM hvilken understøtter både Webex-appen og Jabber, og er den nye standard bløde klient for slutbrugere.
Afhængigt af den eller de implementeringstilstande, der er implementeret for Jabber (IM-kun, kun telefon og/eller fuld UC-tilstand), skal du muligvis også overveje overgangen af arbejdsbelastningerne til Messaging og/eller Møder fra Jabber til. Den kan implementeres i telefon tilstand, hvis den vil blive brugt som en klient, der kun ringer, eller den kan implementeres som fuld, Webex Suite hvis andre arbejdsbelastninger, f.eks. Webex Messagingog/ellerWebex Meetings, bliver overgået til appen med opkald.
Det forbedrer slutbrugerens oplevelse ved at levere AI-funktioner som lyd/ video intelligens, opkaldstransskription og andre. Du kan finde flere oplysninger på https://www.webex.com/all-new-webex.
Før du flytter brugere til, skal du overføre deres Jabber-klienter til. Du har to muligheder for at fuldføre denne overgang.
-
Før du overfører dem til
-
Når du overfører dem til.
For at lette den indledende overgang til, anbefales det at bruge mulighed 1 og flytte brugere til med opkald først. Dette giver brugerne tid til at gøre sig bekendt med den nye applikation, mens de stadig bruger den eksisterende lokale opkaldsplatform. Når du er klar til at flytte brugere til, konfigurerer du dem til at registrere sig på skyopkaldsplatformen.
For mere information om disse to muligheder, se Migrationsrejse - et eller to trin? .
For en komplet liste over de understøttede enheder til, se Under støttede enheder til Webex Calling.
Bekræft enhedens berettigelse
Som nævnt tidligere understøtter det en undergruppe af Cisco IP-telefoner og kræver en anden firmwaretype til telefonerne i 7800 og 8800-serien. Unified CMtelefoner kører Enterprise-firmwaren, mens telefoner kører multiplatform Phone (MPP) firmware. Det anbefales at kontrollere, hvilke registrerede telefoner der er kvalificerede til at opgradere til MPP-firmwaren i forberedelsesfasen. Dette giver dig tid til at erstatte ikke-kvalificerede telefoner med en af de understøttede telefonmodeller eller til at identificere en alternativ plan, som at flytte en bruger kun til Webex-appen.
For at hjælpe med at bestemme telefonernes berettigelse har Control Hub et indbygget værktøj kaldet Migrere din telefon til Webex Calling. Når du bruger dette værktøj til at kontrollere enhedens berettigelse, skal du vælge indstillingen Overførsel Generer kun enhedslicens.
Denne mulighed giver dig mulighed for at uploade en CSV-fil, der indeholder telefonerne, så du kan kontrollere, om hver telefon er berettiget. Ved at vælge denne migreringsindstilling føjer den ikke telefonerne til, da du stadig er i forberedelsesfasen og ikke er klar til at gøre dette endnu. Du kan finde flere oplysninger under Overfør din telefon til Webex Calling.
Det er muligt, at nogle af telefonerne kan komme tilbage med en ukendt berettigelse. Dette skyldes typisk, at det ikke er muligt at validere nogle oplysninger om telefonen i back-end-systemet. For alle telefoner, der har status U kendt, har du to muligheder for at kontrollere, om de er kvalificerede til at opgradere til MPP-firmwaren.
-
Kontroller manuelt hver telefon, og kontroller model- og hardwareversionen (PID VID)
7800/8800 telefonetiket med model- og hardwareversionsoplysninger -
Brug Cisco IP-telefonberedskabsværktøjet
Download værktøjet fra https://github.com/joemar2/mpp_readiness_check.
Dette værktøj er ikke et officielt Cisco-værktøj, og det understøttes heller ikke TAC. Det har den bedste indsatsunder støttelse, men er gratis at bruge.
Dette værktøj skal køres på en computer, der er i det lokale miljø og kan få adgang til serverne og IP-telefonerne. Det har en mulighed for at aktivere webadgang på IP-telefonerne, hvilket anbefales og er nødvendigt for at få de bedste resultater. Derfor bør det bruges i fritiden for at undgå forstyrrelser for slutbrugerne. Udgangen fra værktøjet indeholder en rapport, der viser, hvilke af telefonerne i 7800- og 8800-serien, der er berettiget til at opgradere til MPP-firmwaren. Fordi den direkte får adgang til telefonen, kan den bekræfte de ukendte enheder, der blev rapporteret fra Control Hub-værktøjet.
Rapport om Cisco IP-telefonberedskabsværktøj
Brugere
Et af de vigtigste forberedelsestrin for at sikre, at du har en vellykket overførsel, er korrekt brugerklargøring. Du skal planlægge korrekt for alle brugere, selvom du foretager en trinvis overførsel . Brugere skal være klargjort til et af følgende:
-
Implementering af med opkald
-
Implementering af med
-
Konfiguration af tjenester til en bruger
-
For at gøre brugere søgbare i biblioteket (klik for at ringe, brugerkontaktoplysninger, telefonkatalogsøgning).
Det anbefales, at du klargør alle brugere før eller ved projektets start. Dette inkluderer brugere, der stadig bruger deres op Unified CM kaldsplatform, der er uafhængig af deres opkaldsenhed (IP-telefon, Jabber,). Efterhånden som brugerne bliver migreret til (og/eller), opdaterer du deres licenser for at aktivere de tjenester, de har brug for. Ved at klarlægge alle brugere med virksomhedsopkald, før overgangen påbegyndes, giver den en bruger, der har overgået til eller, mulighed for at søge i mappen efter en virksomhedsopkaldende bruger, der stadig er på Jabber og/eller slået til. Dette sikrer, at overførte brugere kan finde enhver anden brugers kontaktoplysninger og foretage et opkald til dem ved hjælp af katalogopslaget.
Figur katalogsøgningen viser et eksempel på en bruger, der søger efter en anden bruger. Søgeresultaterne viser brugerens kontaktoplysninger og kan være for en bruger, der stadig er på Jabber, og eller for en bruger, der har overgået til og/eller.
Bestem derefter, hvilke af de eksisterende lokale opkaldsbrugere der skal overføres til. Hvis alle eller et stort antal brugere vil blive overgået, anbefales det at flytte brugere i grupper for at sikre, at projektteam, it-personale og supportpersonale er i stand til at håndtere overgangen og eventuelle problemer, der måtte opstå. Du bør også afsætte lidt tid til at give indledende information og træningssessioner for at forberede brugerne på denne overgang. Gruppering af bruger overgange kan udføres baseret på en række kriterier, herunder den placering eller det websted, brugerne er tildelt, brugerafdelinger eller endda brugertyper (vidensarbejdere, ledere, mobile arbejdere osv.).
Hvis brugerne i implementeringen f.eks. er opdelt på tre hovedsteder, New York (NYC), San Francisco (SFC) og Research Triangle Park (RTP), kan en brugerovergangsplan se ud som den plan, der er beskrevet i Brugerovergangsplan for lokalitetstabel.
| Brugerwebsted/placering | Information og træningssessioner før overgangen | Overgangsperiode | Støtte efter overgangen |
|---|---|---|---|
| NYC (1.525 brugere) | Ugen den 1. april | 15. april — 27. april | Ugen 29. april |
| SFO (1.600 brugere) | Ugen den 6. maj | Maj 20 - Maj 31 | Ugen den 3. juni |
| RTP (1.275 brugere) | Ugen den 3. juni | 17. juni — 28. juni | Ugen den 1. juli |
En anden vigtig faktor er at overføre brugere sammen, der har afhængigheder mellem hinanden . Dette kan omfatte, men er ikke begrænset til, følgende:
-
BLF-overvågning
-
Samme jagtpilot/gruppe
-
Del linjer
-
Del af samme gruppe for afhentning af opkald
-
Brug af de samme call-park-numre
-
Intercom
-
Admin/Exec.
Du kan gennemgå konfigurationen (GUI eller eksport) eller bruge værktøjet Migration Insights til at identificere de grupper af brugere med disse afhængigheder.
PSTN-forbindelse
kan få adgang til PSTN på tre måder: Cisco-opkaldsplaner, Cloud connect for (tidligere Cloud Connected PSTN) og lokal PSTN (lokal gateway). En enkelt placering som defineret inden for kan dog kun tildeles til en enkelt PSTN-indstilling.
Lokalt PSTN med en lokal gateway (LGW) er en væsentlig del af overgangsstrategien. Det giver forbindelse mellem den lokale implementering og/eller PSTN og platformen. understøtter både Cisco og certificerede tredjepartssessionsgrænsecontrollere (SBC), der kan bruges som lokal gateway. For den seneste liste over understøttede SBC'er, se Liste over understøttede SB C'er.
understøtter op til 250 samtidige opkald fra en enkelt lokal gateway, der er registreringsbaseret, og mere end 250 samtidige opkald fra en enkelt lokal gateway, der er certifikatbaseret. Certifikatbaserede lokale gateways kan understøtte op til 6500 samtidige opkald, men dette er baseret på den type forbindelse, den lokale gateway skal have (Over-the-Top vs interconnect peering) og den SBC-model, som den lokale gateway er implementeret på. Disse grænser er i det væsentlige standardtællingsgrænsen for både lokale gateway-baserede PSTN-opkald og opkald mellem websteder mellem og slutpunkter. Du kan finde flere oplysninger under Kom godt i gang med lokal gateway.
Alle opkald, der overskrider denne grænse, afvises med en 403 forbudt. Vis opkald aktiv stemmek ommando kan køres på den lokale gateway når som helst for at bestemme det samlede antal aktive opkald.
Dårlige netværksforhold mellem en lokal gateway og adgangsSBC kan begrænse signalforbindelsens ydeevne, hvilket fører til en endnu lavere grænse for samtidige opkald. Envejs ventetid mellem den lokale gateway og datacentret bør ikke overstige 100 ms, og jitter bør være mindre end 10 ms, mens pakketab er mindre end 0,5%.
Funktioner og funktionsbrug
Når du vurderer det aktuelle miljø, er det vigtigt at identificere og gennemgå, hvilke funktioner der er konfigureret. Derudover er det vigtigt at forstå brugen af funktionerne , så du kan (igen) definere dine forretningsmæssige og tekniske krav til din implementering.
For at bestemme, hvilke funktioner der er konfigureret, skal du analysere konfigurationen. Dette er alle statiske data, der indstilles, når en funktion eller indstilling er konfigureret på systemet. Følgende muligheder kan bruges til at fuldføre denne analyse:
-
Gennemgå konfiguration i admin GUI
-
konfigurationseksport - masseeksport eller AXL
-
værktøj til migrationsindsigt (anbefales)
-
Cisco tredjeparts partnerværktøjer (Anbefalet).
For at analysere funktionsudnyttelse effektivt er det vigtigt at undersøge dynamiske systemdata såsom udnyttelse, registreringer og opkald saktivitet. Forskellige analyseværktøjer og dashboards giver indsigt i disse målinger, hvilket muliggør en omfattende forståelse af systemets ydeevne og kapacitet, hvilket understøtter informeret beslutningstagning under migrering og optimering. Følgende muligheder kan bruges til at fuldføre denne type analyse:
-
Gennemgang af rå CDR-poster
-
Gennemgang af Unified CM RTMT-data
-
Migration Insights værktøj ved hjælp af CDR-data
-
Gennemgang af Cloud-Connected UC-analyse i
-
Opkaldsvolumen
-
Registrerede slutpunkter
-
(CAC) placeringer
-
Udnyttelse af bagagerummet.
-
-
Cisco tredjeparts partnerværktøjer.
Cisco anbefaler, at du starter med værktøjet Webex Control Hub Migration Insights til denne analyse. Du importerer din eksport.TAR-fil og Unified CM CDR-filer (valgfrit, men påkrævet til analyse af funktionsud nyttelse) til værktøjet. Værktøjet genererer følgende CSV-baserede rapporter , der kan bruges til at starte analysen:
| Rapportnavn Rapportbeskrivelse |
|---|
| ImportedDataBulk.csv
Alle brugere og enheder fra Unified CM data |
| DeviceEligibility.csv
Identificerer enheder, der er kvalificerede til at migrere til Webex Calling (IP-telefoner, Room OS- enheder, ATA'er og tredjepart) |
| DevicePoolNumbers.txt Liste over alle numre i en bestemt enhedspul je |
| HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv Detaljer om enheder og brugere, der skal migreres sammen baseret på delte linjer, jagt pilot, opkaldskø, opkaldspark og opkaldsafhentningsgruppe |
| HuntGroupMigrationInsight.csv Detaljerede oplysninger om tildelte jag tlinjer, linjegrupper og tilknyttede agenter |
| SharedlineGroupMigrationReport.csv Oversigt over, hvordan telefonnumre (katalognumre) deles mellem brugere |
| Rapportnavn Rapportbeskrivelse |
|---|
| FeatureUsageBasedDeviceEligibilityReport.csv Oplysninger om berettigelse til enheds migration baseret på funktionsbrug |
| FeatureUsageWithLastUsageDateReport.csv Brugstal for det antal gange jagtpilot (er) og opkaldskø (er) er blevet kaldt sammen med den sidste brugs dato |
| UserWorkspaceLastUsage.csv Sidste brugsdato for brugere og arbejdsområder for både bløde klienter og hardtelefoner |
| DIDUsageReport.csv DID-brug for både tildelte og ikke-tildelte DID'er |
Du kan finde flere oplysninger om rapporterne Migration Insights under Overfør sel sindsigt.
Hvis du har brug for flere oplysninger om funktionerne og brugen efter at have gennemgået oplysningerne i Migration Insights-rapporterne, anbefaler Cisco at overveje et af Ciscos tredjepartsmigreringsværktøjer til partnere og/eller at gennemgå konfigurationerne i GUI eller i konfigurationseksportdataene.
Cisco-integrationer: Unity-forbindelse UCCX UCCE
Voicemail er en integreret del af tilbuddet og indbygget i løsningen. kan ikke integreres med en lokalbaseret voicemail-løsning som Unity Connection eller Unity Connection Express. Yderligere, der er ingen indbygget måde at migrere eksisterende Unity-forbindelses voicemail-beskeder eller hilsener til den oprindelige voicemail-tjeneste, der er tilgængelig med. Nogle af Ciscos tredjepartspartners migreringsværktøjer har muligheder for at migrere nogle af disse data. Du kan finde flere oplysninger om telefonsvarer til under Konfigurere og administrere indstillinger for telefonsvarer for en bruger. Webex Calling
understøtter også delte telefonsvarer og faxpostkasser. Du kan finde flere oplysninger i Administrer en delt telefonsvarer og indgående fax boks for. Webex Calling
har en indbygget Auto Attendant-funktion, der er inkluderet som en del af kerneplatformen. Denne funktion giver mulighed for overgang af din Unity Connections opkaldshåndterere og automatisk ledsager funktionalitet . Værktøjet Control Hub, Migrere funktioner fraUnified CM, understøtter migrering af Unity-forbindelseskonfigurationer til automatiske ledsagere. Du kan finde flere oplysninger om brug af dette værktøj under Overførsel af enheder og funktioner fra Unified CM tilWebex Calling.
Opkaldsoptagelse
inkluderer to muligheder for opkaldsoptagelse uden ekstra omkostninger.
-
Webex opkaldsoptagelse
-
Dubber Go-optagelse (partnertilbud) - en integration mellem og dubber, hvor alle optagede medier opbevares sikkert i skyen.
Inkluderet optagelses indstillingstabel fremhæver nogle nøglefunktioner i de to opkaldsoptagelsesmuligheder, der er tilgængelige uden ekstra omkostninger.
| Webex | Double Go |
|---|---|
| Tilgængelig for alle brugere | Tilgængelig for alle brugere |
| Ubegrænsede optagelser | Ubegrænsede optagelser |
| 1 års opbevaringsperiode* | 30-dages opbevaringsperiode |
| 100 GB lagerplads pr. Org | - |
| Compliance-medarbejdere kan få adgang til og administrere opkaldsoptagelser | - |
| API'er til styring af optagelser | - |
Administratorer kan konfigurere og administrere brugernes adgang til deres opkaldsoptagelser
|
Kun brugere kan få adgang til og administrere deres optagelser
|
Hvis din organisation kræver yderligere optagefunktioner som op tagelse af overholdelsesopkald, længere opbevaringsperioder, mere lagerplads, AI-analyse og/eller administratoradgang, findes der betalte tilbud eller tilføjelser fra både Cisco og tredjeparts optagelsesudbydere. Du kan finde flere oplysninger om optagelsesudbydere, konfigurationer og tilføjelsespartnertjenester under Administrer opkaldsoptagelse for Webex Calling.
Tredjepartsintegrationer
understøtter en række tredjepartsintegr ationer, herunder men ikke begrænset til SBC'er til lokale gateways, IP-telefoner, intercom-telefoner, højttaler/personsøgere, ATA'er osv. Ud over disse tredjepart sen heder Webex Calling understøtter de forskellige tredjepart sl øsninger til kundesupport, analyse, optagelse, fakturering osv. Du kan finde flere oplysninger om tredje partsløsninger under Webex App Hub.
Planlæg
Projektplan på højt niveau
Når man udvikler en projektplan på højt niveau for migrering fra til, er det vigtigt at etablere klare faser og milepæle, der stemmer overens med både forretningsmæssige mål og tekniske krav. Planen bør begynde med en omfattende vurderings fase, herunder indsamling af detaljerede tekniske og forretningsmæssige krav, samt identifikation af interessenter og definition af succeskriterier. Nøgleovervejelser inkluderer ressource allokering, tidslinjeestimering, risikostyring og kommunikationsstrategier for at sikre, at alle parter er informeret og engageret under hele migrationen. Derudover bør planen omfatte validering skontrolpunkter såsom pilottest og trinvise udrulninger for at minimere forstyrrelser og give mulighed for justeringer baseret på feedback.
Eksempler på elementer, der skal medtages i projektplanen, er:
-
Definere omfanget af migrering (f.eks. hvilke brugere, enheder og funktioner der skal overgå)
-
Planlægning af træningssessioner for slutbrugere og supportteams
-
koordinering af vurderinger af netværksberedskab og
-
Planlægning af cutover-aktiviteter med fallback-muligheder. Det er også vigtigt at integrere overholdelses- og sikkerhedsvurderinger samt support- og optimerings faser efter migrering.
Ved at strukturere projektplanen med disse overvejelser kan organisationer bedre styre kompleksitet, reducere risici og opnå en glattere overgang til.
Migrationsrejse - et eller to trin?
kræver, at brugerne bruger den til deres opkaldende soft klient. Derfor, hvis nogen brugere stadig bruger, har du to muligheder for, hvornår du kan flytte dem til. Du kan enten foretage en brugeroverførsel i et enkelt trin eller en brugeroverførsel i to trin.
Valgmulighed 1: Enkelttrinsbrugermigrering
I et enkelt trin overgår brugerne fra til det, samtidig med at de overgår fra Unified CM til. Denne mulighed er typisk for kunder med et lille antal brugere at migrere og kan administrere at flytte både brugerens bløde klient og opkaldstjeneste til på samme tid. Figuren Brugerens opkaldstjeneste, softklient og telefon migrerer til på samme tid nedenfor fremhæver denne type migration. Med denne mulighed vil en bruger have følgende gennemført på samme tid:
-
Opkaldstjenester flyttet fra til
-
Telefonnumre og udvidelser flyttet fra til
-
Soft client overgik fra Jabber til - vil registrere sig til
-
Telefonregistrering flyttet fra til.
Dette kan stadig være en trinvis overførsel, hvor grupper af brugere flyttes på forskellige tidspunkter, men når hver bruger flyttes, sker alle disse på samme tid.
Mulighed 2: Migrering af brugere i to trin
Den anden tilgang er en totrinsmigration. I trin 1 skiftes brugerne fra til, men forbliver på opkaldstjenester. Derefter flyttes brugerne i trin 2 fra Unified CM til. Denne indstilling anbefales til større kunder til at administrere slutbrugerændringerne og ønsker at ad skille brugerens bløde klientændring fra ændringen af opkaldstjenesten. Følgende figur Migrere blød klient; derefter migrere opkaldstjeneste, softklient og telefon til Webex Calling nedenfor fremhæver denne type overførsel.
Trin 1
-
Soft client overgået fra til - vil registrere sig til.
Trin 2
-
Opkaldstjenester flyttet fra til.
-
Telefonnumre og udvidelser flyttet fra til.
-
registrering flyttet fra til.
-
Telefonregistrering flyttet fra til.
Dette kan stadig være en trinvis migrering, hvor grupper af brugere flyttes på forskellige tidspunkter i begge trin.
Den indstilling, du vælger, afhænger af, hvordan du vil administrere dine brugeres overgang til og. Anbefalingen er at tage det i trin (mulighed 2). Dette giver dig mulighed for at minimere slut brugerens ændringer på én gang og opdele indsatsen på tværs af forskellige dele af projektet. Men hvis du foretrækker at have brugere kun påvirket én gang, er brug af mulighed 1 også gyldig.
Når man ser på den anbefalede rejse (mulighed 1), viser overgangskortet Jabber til Webex App på højt niveau nedenfor overgangen på højt niveau for trin 1.
I dette trin overgår brugerne fra Jabber til alle deres opkaldstjenester. Opkaldsplatformen er dog stadig, Unified CM og den vil registrere sine opkaldstjenester til. Som det ses i overgangskortet Jabber til Webex App på højt niveau ændres infrastrukturen i det lokale miljø ikke, og det fungerer på samme måde, som Jabber gør. Den eneste ændring er, at der kræves en forbindelse ud til.
Du kan finde flere oplysninger om denne overgang i Vej ledning til overgangskort og implementering af Jabber til Webex under afsnittet Klient på siden Samarbejdsovergang.
Unified CMtil over Webex Calling gangskortfigur på højt niveau er over gangen på højt niveau fra til. Dette er trin 2 af den anbefalede rejse.
Hvis du beslutter dig for at bruge enkelttrinsmetoden, gælder dette også.
I dette trin overføres brugere til i grupper. På dette tidspunkt begynder brugerne at bruge til deres opkaldstjenester, opkaldsregistrering og IP-telefonregistrering.
Da brugerne bevæger sig i grupper, vil Enterprise-brugere blive delt mellem de to opkal dsplatforme under overgangen. Fase 1 i Unified CMover gang Webex Calling skortfiguren på højt niveau viser denne tilstand. I denne fase kræves planlægning for, hvordan man administrerer opkald mellem brugere på de to platforme, og hvordan PSTN-opkald vil blive dirigeret. Hver gang en gruppe brugere skiftes til, kræves der opkaldsplaner og opdateringer af opkaldsruting på og den eller de lokale gateway (er).
Når alle brugere, bløde klienter og enheder er blevet overført til (fase 2), kan al lokal UC-infrastruktur fjernes og tages ud af drift.
Udformning
Valg af region
er tilgængelig globalt og leveres fra redundante datacentre i flere regioner: USA (Dallas, Chicago), Canada (Vancouver, Toronto), Europa (Frankfurt, Amsterdam), Storbritannien (London, Manchester), Australien (Melbourne, Sydney), Japan (Tokyo, Osaka), Saudi-Arabien (Riyadh, Jeddah) og Indien (Mumbai, Chennai). Medie-POP'erne leverer medietjenester for at optimere mediernes rundturtider. Singapore-datacentret bruges for eksempel til at optimere mediernes tur -returtider for kunder i asiatiske lande, hvor rundturstiderne til enten Australien eller Japan- regionen kan være suboptimale. Datacentrene er forbundet med en multi-gigabit og fuldt redundant rygrad. Figuren globalt distribuerede datacentre viser et overblik over alle datacentre. For den seneste liste over tilgængelige datacentre, se Datacenterplaceringer for Webex Calling.
Hver kunde er klargjort på en af instanserne. Alle klargøringsoplysninger for den pågældende kunde gemmes i den pågældende instans, og SIP-signaleringen af alle slutpunkter og lokale gateways, der er klargjort for den pågældende kunde, er bundet til den forekomst, kunden er klargjort på. Fordi det er svært at ændre det oprindelige regionvalg, er det vigtigt at overveje alle relevante faktorer som en del af beslut ningsprocessen, der fører til regionudvælgelsen. For at undgå overdreven signalreturforsinkelse er det vigtigt tidligt i overgangsprocessen at beslutte, hvilken instans der skal bruges. Cisco anbefaler, at du vælger den forekomst, der giver de laveste signaleringstider for det største antal brugere inden for implementeringen.
Se Hvor er Webex tilgængelig? Se, hvor er Webex tilgængelig? .
Lokaliteter
For at forberede klargøring af placeringer skal de nødvendige oplysninger for alle overførselsmål indsamles. De oplysninger, der er nødvendige for hver placering, er opsummeret i Oplysninger, der skal indsamles for hver placering.
| Oplysning | Kommentar |
|---|---|
| Udvidelsesområde (r) | Hver placering i kan have udvidelser, der starter med forskellige cifre. Der skal spares et ciffer for
styretumstallet mellem lokalerne (f.eks. 8) og et for PSTN-
styretumcifferet (f.eks. 9). Intet udvidelsesområde kan starte med nogen af
disse to cifre. Alle udvidelsesintervaller på alle placeringer skal være af samme længde. |
| DID-område (r) | - |
| PSTN styretøj | - |
| Webstedskode | Alle webstedskoder på alle placeringer skal være unikke og have samme længde. |
| Hovednummer | Når du opretter en placering, skal to DID'er klarlægges. Et som
hovednummer (for eksempel til at blive tildelt en automatisk svartjeneste) og et til telefonsvar
erportalen. Bestem en DID til telefonsvarernummeret. |
| Voicemail nummer | |
| Antal licenser | Påkrævede licenser efter type inklusive Standard, Professional, Workspace, Ruteliste, Udgående opkaldsplan. |
| Samtidige opkald i den travle time | Summen af samtidige opkald mellem enheder og mellem enheder og den lokale gateway (PSTN og opkald til enheder). Nødvendigt for at bestemme den nødvendige båndbredde til internetadgang. |
| Land | - |
| Tidszone | - |
| Sprog | - |
| Kontakt (Navn, Telefon, E-mail) | - |
| Adresse (gadeadresse, by, stat, postnummer) | - |
| Redningstjenesternes fysiske afsendelsessted for slutpunkter | Enhedens afsendelsessted, der bruges til nødopkald, omfatter generelt følgende: bygningsadresse, bygningsadresse + etagenummer, bygningsadresse + suite nummer eller bygningsadresse + etagenummer + kontor/kubiknummer. |
| Entydig fysisk netværksplacering pr. enhed for alarmtjenester | Fysisk netværksplacering til nødopkald omfatter generelt følgende: switch/switchport til kabelforbundne enheder, BSSID'er (Wireless Access Point) Basic Service Set Identifiers (BSSID'er) for trådløst tilsluttede enheder og/eller lokale IP-undernet (er) til slutpunktsenheder. |
PSTN
Når kunderne designer en udrulning, har kunderne tre primære PSTN-tilslutningsmuligheder: Cisco C alling-planer (en cloud-leveret PSTN-tjeneste administreret af Cisco), Cloud Connec ted PSTN-udbydere (CCPP, hvor udbydere leverer PSTN-tjenester via skyen) og PSTN i det lokale miljø (hvor lokale gateways forbinder virksomhedsnetværket med PSTN). Med introduktionen af PSTN-trunking til hybrid-implementeringer (for mere information, se PSTN-trunking til hybrid-implementeringer ved PSTN-trunking) får Webex Calling organisationer yderligere fleksibilitet i deres migreringstilgang. Denne funktion gør det muligt for kunder at flytte deres PSTN til CCPP i starten af overgangs rejsen og begynde overgangen til cloud PSTN for brugere, mens de udnytter CCPP til at opretholde PSTN-service for brugere, der forbliver på Cisco under en trinvis migration.
Denne hybride tilgang giver organisationer mulighed for først at flytte udvalgte brugergrupper til skyen uden straks at revidere hele deres telefonimiljø. Det introducerer dog yderligere kompleksitet og risiko, især omkring tilpasning af eksisterende opkaldsroutingslogik til at understøtte den nye arkitektur. Interoperabilitet med ældre applikationer, såsom faxservere, kontaktcentre eller personsøgnings systemer, kræver også nøje overvejelse. De vigtigste tekniske udfordringer kan omfatte sikring af problemfri end-to-end-codec-forhandling og DTMF-signalering (Dual-Tone Multi-Frequency) på tværs af det blandede miljø samt validering af kompatibilitet med specialiserede telefonifunktioner. Korrekt planlægning og test er afgørende for at minimere forstyrrelser og opretholde pålidelige taletjenester gennem hele migrationsprocessen. Derudover er kommercielle overvejelser vigtige, da hybrid trunking kræver en brugslic ens, der er baseret på antallet af samtidige opkald mellem det lokale miljø og Cloud Connected PSTN Provider (CCPP).
Alternativt kan organisationer vælge at bevare deres lokale PSTN-forbindelse gennem hele overgangsfasen. I dette scenarie kan migrering til CCPP udføres på to måder: som en enkelt, koordineret cutover for alle brugere og placeringer, når migreringen er afsluttet, eller trinvist, hvor PSTN-migrering finder sted pr. placering, når brugerne flyttes til. Denne tilgang kan hjælpe med at strømline sameksistens og opretholde kontinuitet for ældre integrationer, men det introducerer flere operationelle kompleksiteter. Blandt disse er udfordringer relateret til nummerportering, såsom behovet for præcis koordinering af nummerportordrer, potentielle forsinkelser, og udbyderpålagte begrænsninger som et loft på antallet af samtidige portanmodninger eller begrænsninger for portering af delsæt af store antalblokke. Organisationer skal omhyggeligt planlægge deres PSTN-overgangsstrategi og tage højde for disse logistiske overvejelser for at undgå serviceafbrydelser og sikre en problemfri migrationsoplevelse.
Figuren Overførsel til CCCP i starten vs. opbevaring af PSTN i det lokale miljø viser de to PSTN-overførselsin dstillinger, der er beskrevet ovenfor. Illustrationen til venstre viser scenariet, hvor alle brugere og programmer i det lokale miljø bruger Cloud Connec ted PSTN-tjenester via en on-premises trunk og en lokal gateway, der forbinder det lokale miljø med, mens illustrationen til højre viser scenariet, hvor det eksisterende lokale PSTN forbliver på plads, og brugere anvender PSTN i det lokale miljø via den lokale gateway-forbindelse mellem det Webex Calling lokale miljø og. Under overgangen kan placeringer skiftes til ved hjælp af Cloud Connected PSTN.
I begge scenarier bruger opkald mellem det lokale miljø og brugeren den lokale gateway-forbindelse. Forbindelsen mellem lokalt og skal designes og dimensioneres i overensstemmelse hermed baseret på det forventede antal samtidige opkald og den krævede redundans.
Opkaldsplan
For at opnå problemfri interoperabilitet mellem og i migrationsperioden skal der udvikl es og implementeres en omfattende opkaldsplanarkitektur på tværs af begge platforme. Dette opkaldsplandesign med to platforme sikrer ensartet opkal dsrouting, nummeroversættelse og funktionsgennemsigtighed, hvilket gør det muligt for brugere på begge systemer at kommunikere uden tjenesteforringelse eller forstyrrelser i brugeroplevelsen i hele sameksistensfasen.
Opkaldsplan i det lokale miljø
Under overgangen for at muliggøre sameksistens mellem enheder, der er registreret på Unified CM og på virksomheden, skal opkaldsplanen ændres, så som minimum følgende krav kan opfyldes:
-
+E.164 opkald fra til
-
Udvidelsesopkald fra til (internt på stedet, men også mellem lokaliteter, hvis udvidelsesområderne er unikke)
-
Forkortet opkald mellem websteder fra til
-
Tvunget opkald på nettet fra til
-
Tilbagekald fra mappen for ubesvarede opkald til destinationer på
-
PSTN-opkald fra til PSTN, hvis der under overgangen bruges det lokale PSTN til
-
PSTN-opkald fra til hvis under overgangen PSTN-trunking til hybridinstallationer bruges til at give PSTN-adgang til brugere i det lokale miljø via Cloud Connect til
-
Tvunget på nettet fra til
-
Udvidelsesopkald fra til (mellem websteder).
Hvis nogen af ovenstående ikke er understøttede opkaldsvaner før overgangen, for eksempel eksisterer der ingen forkortet opkaldsvane mellem websteder, behøver de ikke nødvendigvis at indføres under overgangen.
Figur Opkalds plan for bedste fremgangsmåder viser den bedste fremgangsmåde for opkaldsplan som beskrevet i Preferred Architecture for Cisco Collaboration 12.x Enterprise On-Premises Imployments, CVD. Nøglekarakteristika ved denne tilgang inkluderer:
-
Enkelt partition til+E.164 katalognumre
-
Kernerutning baseret på+E.164 rutemønstre
-
Normalisering af alle opkaldsvaner til+E.164 ved hjælp af oversættelsesmønstre
-
Brug af oversættelsesmønster, der kalder arv af søgerum (mulighed Brug ophavsmandens opkal dssøgerum ind stillet på oversættelsesmønstre).
For eksempel vil PSTN-opkald (9+1+10D) fra en enhed i SJC, der er forsynet med sø geområde for linjeopkald SJCinternational, først blive matchet af oversættelsesmønsteret 9.1 [2-9] XX [2-9] XXXXXX, som normaliserer det opkaldte partnummer til +E.164. Det sekundære opslag bruger derefter det samme opkaldssøgningsrum SJCinternational igen (kalder søgerumsarv), og strengen +E.164-cifrede vil enten blive matchet af et +E.164-mappenummer i DN-partitionen eller af et af PST N- rutemønstrene i partitionen USPSTNnational eller SJCPSTNLocal. Forkortede intra-site- og inter-site-opkaldsvaner implementeres af oversættelserne i ES N- og SJCTOE164-partitionen. Mens ESN- partitionen er en global partition (tilgængelig for telefoner på alle placeringer), er SJCTOE16 4-partitionen kun tilgængelig for brugere på stedet SJC. Dette forudsætter overlappende udvidelsesintervaller.
Det første skridt til at aktivere opkald fra til er at sikre, at +E.164-destinationer bliver dirigeret i overensstemmelse hermed. Dette kan opnås ved at tilføje en partition til opkaldsplanen, tilføje+E.164 rutemønstre for alle destinationer til den partition og til sidst tilføje partitionen til alle opkaldende søgerum, der repræsenterer klasser af tjenester, som skal være i stand til at nå. Oprettelse af en dedikeret partition er påkrævet for at muliggøre oprettelse af en differentieret serviceklasse til opkald, der stammer fra. For at undgå opkaldssløjfer bør det indgående opkaldssøgningsrum på bagagerummet fra den lokale gateway ikke have adgang til partitionen.
Som vist i figur +E.164 routing tilWebex Calling, for at muliggøre routing fra til for en placering med+E.164 DID-rækkevidde +1 221 555 2XXX og webstedskode 121, skal der tilføjes et presserende rutem ønster, der matcher dette+E.164-område, til partitionen.
Hvis der ikke kræves et stedspecifikt valg af lokal gateway, kan der i stedet for at bruge en ruteliste med en lokal rutegruppe som destination for rutemønstre, der peger på en enkelt rutegruppe, klarlægges med den lokale gateway som det eneste medlem, og derefter peger rutemønstrene på en enkelt ruteliste med denne ene rutegruppe som eneste post.
For at aktivere forkortet opkald mellem websteder til webstedet tilføjes det krævede rutemønster 8121.2XXX til partitionen. For websteder, der skal overføres til et opkaldsnormaliseringsmønster 8121.2XXX, der normaliserer ESN-opkald til +E. 164, findes muligvis allerede i ESN-partitionen. I så fald synes 8121.2XXX at være overflødig, men så snart alle DN'er på den respektive placering er blevet migreret over til 8121.2XXX-opkaldsnormaliseringsnormaliseringsmønsteret kan fjernes, og derefter muliggør rutemønsteret 8121.2XXX ESN-opkald, selv for brugere, der kun er udvidelsesbrugere i det pågældende område.
Med disse opkaldsplanændringer kan opkald til lokationen foretages ikke kun ved at ringe forkortet inter-site og +E.164. Desuden er internationale og nationale PSTN-opkald mulige, fordi disse opkaldsvaner først normaliseres til +E.164 gennem de allerede eksisterende oversættelsesmønstre for opkaldsnormalisering og derefter dirigeres til ved at matche +E.164-rutemønsteret i partitionen.
+E.164-rutemønstermatchningen på placeringens DID-område kan klarlægges, mens alle DID'er stadig er aktiveret. Den bedste matchende algoritme til matchende mønstre sikrer, at når der ringes op til et nummer, der er hostet på, er +E.164-katalognummeret, der er klargjort på, bedre match end rutemønsteret +E.164 med jokertegn, der peger på, så opkaldene udvides til en linje på og ikke sendes til.
opkaldsplan
Hver bruger er forsynet med en udvidelse og/eller et+E.164-telefonnummer. Udvidelseslængden er en fast global indstilling: alle udvidelser i en installation har samme længde. Udvidelsesopkald kan bruges mellem brugere både inden for et sted og mellem lokationer. Forkortet udvidel sesopkald mellem websteder (sidstnævnte tilfælde) fungerer kun, hvis den opkaldte udvidelse er unik.
Hvis forkortet opkald mellem websteder mellem lokationer er et krav, men der er overlapninger mellem udvidelser, der er tildelt forskellige placeringer, skal der oprettes en virksomhedsspecifik nummereringsplan ved at præfiksere udvidelserne med en adgangskode, en webstedskode. Du kan finde flere oplysninger under Fore trukken arkitektur for Cisco Collaboration 15 On-Preparate Imployments, Oversigt over design på Ciscos foretrukne arkitekturer for samarbejde.
Udvidelseslængden, opkaldsfunktionsmåden mellem lokaliseringsudvidelserne, præfikslængden for opkald mellem lokaliteter og styretumcifferet i routingpræfikset for opkald mellem lokaliteter er konfigureret i indstillingerne for opkaldstjenesten i:
-
Placeringsrutepræfikslæng de: Præfikslængde inklusive styretummeret. Kræ ves kun, hvis der skal etableres en virksomhedsnummerplan som alternativ forkortet virksomhedsopkaldsvane mellem lokaliteter.
-
Styretøj i routingpræfiks: Styretumstal for forkortet opkal dsvane mellem virksomheder. Overlapninger med første ciffer på ethvert sted og udgående opkaldscifre bør undgås. Kræ ves kun, hvis der skal etableres en virksomhedsnummerplan som alternativ forkortet virksomhedsopkaldsvane mellem lokaliteter.
-
Intern forlængelseslængde: Standard længde af forlængelser. Kan være en hvilken som helst værdi mellem to og ti.
Når der kræves opkald eller opkald ved hjælp af virksomhedssignifikante numre (styrekode, webstedskode, udvidelse) fra en opkaldskontrol i det lokale miljø til, og opkaldskontrollen i det lokale miljø sender en udvidelse som opkalds-id, skal du sørge for også at angive parameteren Maksimal ukendt forlængelseslængde i afsnittet Opkaldsdirigering mellem og lokaler for at sikre, at opstrømsopkald fra opkaldskon trollen i det lokale miljø kan klassificeres korrekt som opkald i det lokale miljø. -
Tillad opkald til udvidelsesopkald mellem lokationer: Ski ft for at aktivere/deaktivere opkald til udvidelsesopkald mellem lokationer . Denne indstilling bør kun aktiveres, hvis alle udvidelser i organisationen er unikke. Hvis indstillingen er deaktiveret, skal der ringes til virksomhedssignifikante numre (styrekode, webstedskode, filtypenavn) eller telefonnumre mellem lokationer.
De første tre parametre bruges hovedsageligt til at opbygge en opkaldsplan for telefoner for at minimere intercifrede timeouts, når du bruger off-hook-opkald. Afvigelser fra disse globale indstillinger er stadig mulige (Eksempel - udvidelser med en anden længde kan etableres), men der vises en advarselsmeddelelse i Control Hub, og opkald fra telefoner kræver muligvis blo kering af opkald for at undgå konflikter inden for den forudindlæste opkaldsplan.
Tabellen Enterprise nummereringseksem pel viser et eksempel på tre placeringer, hvor ud videlsesområderne for to placeringer, NYC og RTP, er identiske. Oprettelse af et virksom hedsnummereringsskema med styringsciffer 8 mellem websteder, efterfulgt af en trecifret webstedskode, og den firecifrede udvidelse skaber en ikke-overlappende forkortet opkaldsvane mellem websteder.
| Websted | Udvidelsesområde | Webstedskode | Enterprise-sortiment |
|---|---|---|---|
| NYC | 2XXX | 202 | 8 202 2XXX |
| SFO | 3XXX | 203 | 8 203 3XXX |
| RTP | 2XXX | 204 | 8 204 2XXX |
For at muliggøre en jævn overgang bør sættet af opkaldsvaner for brugere før og efter overgangen til ideelt set være det samme. For at forberede overgangen for hvert sted skal DID-intervaller og udvidelsesintervaller (eller forkortede interne opkaldsvaner) dokumenteres. Bas eret på disse oplysninger skal styringscifferet mellem stederne vælges.
Tabellen For længelsesintervaller med fast længde viser et eksempel på tre placeringer og forlængelses områder med fast længde. Da overlappende opkaldsvaner skal undgås, er det vigtigt at sikre sig, at det første ciffer i rækkevidden ikke stemmer overens med styretumstallet for forkortet opkald mellem lokaliteter. Hvis for eksempel 8 er valgt som styringsciffer for opkald mellem lokaliteter, kan intet udvidelsesområde på noget sted starte med 8. Typisk matcher udvidelserne på et givet sted de sidste par cifre i DID'erne, der er tildelt den pågældende placering. For at undgå konflikter kan det første ciffer i udvidelsen ændres. Hvis for eksempel DID'er i +1 408 555 8XXX-området bruges på et sted, kan 7XXX bruges til udvidelserne på det pågældende websted i stedet for at bruge 8XXX som udvidelsesområde
| Websted | Udvidelsesområde | Udvidelser | Webstedskode | Enterprise-sortiment |
|---|---|---|---|---|
| NYC | 2XXX | 2XXX | 202 | 8 202 2XXX |
| SFO | 8XXX | 7XXX | 203 | 8 203 7XXX |
| RTP | 1XX | 11XX | 204 | 8 204 11XX |
Syvcifrede opkaldsstrenge, der er opkaldt på en enhed ved hjælp af den amerikanske opkaldsplan, overlapper med et syvcifret mønster til lokal opkald i den forudindlæste amerikanske opkaldsplan. For at undgå overlapninger mellem opkaldsvaner på nettet og uden for nettet (PSTN) kan der anvendes en obligatorisk ekstern adgangskode på det pågældende sted. Hvis det eksisterende virksomhedsnummereringsskema og det tilsvarende forkortede opkald mellem websteder overlapper med mønstre i det nationale opkald, kan det under overgangen til nummereringsskemaet for at undgå overlapninger også ændres til en længere eller kortere form. Den nemmeste måde at opnå dette på er at tilføje et ekstra polstret ciffer til nummereringsskemaet. Det nye længere opkaldsskema mellem websteder skal kun vedtages af brugere, der allerede er migreret til. Brugere, der stadig er på, kan fortsætte med at ringe til syv cifre. Virksomhedsopkaldsplanen, der er aktiveret, skal i dette tilfælde sikre, at den forkortede syvcifrede opkald fra Unified CM til bliver omdannet til enten +E.164 eller til det forkortede opkaldsformat, der er implementeret på. Dette skal gøres, før du sender opkaldet til den lokale gateway.
Den syvcifrede opkald i tabelovergangen viser et eksempel på denne omnummerering. I dette eksempel bruger forkortet opkald mellem websteder styretøj 8 efterfulgt af en tocifret webstedskode og en firecifret udvidelse. For at undgå syvcifret forkortet opkald mellem websteder for placeringer på, kan webstedskoderne let ændres til tre cifre ved at præfixere et vilkårligt polstring ciffer (8 i eksemplet) til de tocifrede webstedskoder, der bruges i, så opkald mellem websteder fra telefoner bruger styrecifret 8 efterfulgt af polstringcifferet 8, den gamle tocifrede webstedskode og den firecifrede udvidelse. Brugere på behøver ikke at huske nye webstedskoder; de behøver kun at huske at bruge 88 som præfiks til opkald mellem websteder i stedet for 8 på.
| Websted | Udvidelser | Webstedskode | Enterprise-sortiment | Site ode | 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 |
I et scenarie med forskellige virksomhedsnummerformater aktiveret, og hvis virksomhedsnumre vises som oplysninger om den opkaldende part for opkald fra til (for eksempel - Opkald fra enheder uden DID), er det vigtigt også at implementere en kortlægning mellem de forskellige nummerformater for oplysninger om den opkaldende part for at sikre, at tilbagekald fungerer. Denne kortlægning kan opnås ved at bruge transformationsmønster for opkaldsparti på bagagerummet mellem og den lokale gateway.
Optagelse
En veludviklet opkaldsoptagelsesløsning kræver nøje overvejelse af flere centrale designelementer for at sikre, at den stemmer overens med organisatoriske mål, lovkrav og tekniske begrænsninger. To af de mest kritiske beslutninger involverer udvælgelse af udbydere og valg af region, som begge kan være nødt til at skræddersys globalt og tilsidesættes på bestemte steder, baseret på forretningsbehov.
1. Valg af udbyder af opkaldsoptagelse
Valg af den passende udbyder af opkaldsoptagelser er grundlæggende for at opfylde forret ningsmæssige mål og sikre tilpasning af funktioner på tværs af organisationen:
-
Valg af global udbyder: Organisationer udpeger typisk en primær udbyder af opkalds optagelser på globalt niveau, hvilket sikrer konsistens i funktionssæt, overholdelse og support på tværs af alle lokationer
-
Placeringsbaserede tilsidesættelser: I scenarier, hvor bestemte lokal iteter eller regioner har unikke forretningsbehov eller lovkrav, kan det være nødvendigt at tilsidesætte det globale udbydervalg og angive alternative udbydere til disse lokaliteter. Denne fleksibilitet understøtter forskellige overholdelsesmandater og lokale operationelle behov
-
Forretningskrav: Valget af udbyder bør være drevet af en vurdering af virksomhedsdrivere såsom overholdelse af lovgivningen (eksempel - MiFID II, HIPAA), kvalitetssikring, tvistbilæggelse eller uddannelsesbehov
-
Funktionstilgængelighed: Udbydere bør evalueres ud fra deres evne til at levere krævede funktioner, såsom realtidsovervågning, søge- og afspilningsfunktioner, kryptering, opbevaringspolitikker, integration med analyseplatforme og support til forskellige opkaldstyper (indgående, udgående, interne).
2. Valg af region
Det er afgørende for overholdelse og ydeevne at bestemme det område, hvor opkaldsoptagelser gemmes og behandles:
-
Valg af globalt område: Som standard kan organisationer vælge et enkelt område til lagring af opkaldsoptagelser for at forenkle administration og styring
-
Lokationsbaserede områdetilsidesættelser: Når love om dataopholdssted eller virksomhedspolitikker kræver det, kan det være nødvendigt at tilsidesætte den globale regionindstilling for bestemte placeringer og sikre, at opkaldsoptagelser gemmes og behandles inden for de krævede geografiske grænser
-
Krav til dataopholdssted: Designet skal tage højde for internationale og lokale databeskyttelsesregler (såsom GDPR, CCPA eller landespecifikke mandater), som kan diktere, hvor og hvordan opkaldsoptagelser opbevares.
Et andet kritisk aspekt, der skal behandles under planlægningen og designet af en opkaldsoptag elsesløsning til, er estimering af lagerbehov. Nøjagtig forudsigelse af lagerbehov er afgørende for at sikre, at der er tilstrækkelig kapacitet til rådighed til at understøtte igangværende forretnings drift, opretholde overholdelse og undgå serviceforstyrrelser.
Flere nøgleparametre bør overvejes, når det forventede lagerbehov bestemmes:
-
Volumen af optagede opkald: Vurder det forventede antal opkald, der vil blive optaget inden for et givet tidsinterval (f.eks. pr. dag, uge eller måned). Dette omfatter ikke kun eksterne opkald, men også intern kommunikation, hvis det kræves af forretningspolitik eller lovgivningsmæssige mandater
-
Gennemsnitlig opkaldsvarighed: Beregn den typiske længde af optagede opkald, da længere opkald vil forbruge mere lagerplads. Variationer i opkaldsvarighed på tværs af forskellige afdelinger eller brugergrupper bør også medregnes i estimatet
-
Opbevaringsperiode: Definer, hvor lang tid optagelser skal opbevares, hvilket ofte er dikteret af organisatoriske politikker eller eksterne regler (f.eks. branchespecifikke overholdelsesstandarder). Længere opbevaringsperioder øger det samlede opbevaringsbehov
-
Vækstprognoser: Overvej forventet vækst i opkaldsmængder eller udvidelse af registreringsomfanget, som kan skyldes virksomhedsskalering, nye lovkrav eller onboarding af yderligere brugere eller lokationer.
Ved grundigt at analysere disse parametre kan organisationer udvikle en robust storagestrategi, der sikrer skalerbarhed, omkostningseffektivitet og overholdelse af lovgivningen for deres opkaldsoptagelsesløsning. Det anbefales også regelmæssigt at gennemgå og justere lager allokeringer, efterhånden som brugsmønstrene udvikler sig over tid.
Nødopkald
Kravet om at dirigere et nødopkald til det relevante forsendelsescenter er et krav for enhver opkaldstjeneste, der tilbyder PSTN-service. Med er routing af nødopkald hjemmehørende i løsningen og inkluderer support til alle nationale alarmnumre i de lande, der understøtter. Routingen af et nødopkald ind er baseret på den placering, der er defineret inden for og PSTN-adgangsmetode for lokaliteten. Alarmnumrene i er foruddefinerede og specifikke for det land, som brugerne og enhederne er implementeret i.
Der er to metoder til at levere nødopkald. Der er en grundlæggende rutetjeneste for nødopkald og en forbedret nødopkalds routingstjeneste. Den grundlæggende rutetjeneste for nødopkald bruger et administratorvalgt nummer til at identificere placeringen og opkaldsruten for at nå nødtjenester. For grundlæggende nødopkald er opkaldsstien typisk gennem kundens PSTN-mulighed for det pågældende lokation. har også forbedret nødopkaldsrouting designet til implementeringer i USA og Canada, der har lovgivningsmæssige overholdelseskrav, der kræver brug af en landsdækkende udbyder til at levere nødopkald til det korrekte forsendelsescenter.
Alle kunder skal som minimum implementere den grundlæggende nødopkaldskonfiguration. Grundlæggende nødopkald kræver, at der tildeles mindst et kundeejet +E.164-nummer til hvert sted, der er defineret i. Ved grundlæggende nødopkald vil hver placering blive defineret af en gadeadresse, som politi, brand- eller ambulancetjenester sendes til i nødstilfælde. I de fleste tilfælde er hovednummeret for placeringen det bedste valg til at repræsentere den fysiske placering af nødsituationen. Typisk koordineres tildelingen af adressen til+E.164-nummeret med PSTN-udbyderen. Billederne nedenfor viser tildelingen af hoved nummeret, der skal bruges som nødopkaldsnummer for Richardson-placeringen.
I de fleste situationer er en bygningsadresse tilstrækkelig til afsendelsesadressen for stedet. Men hvis der er behov for yderligere placeringsoplysninger for bestemte brugere eller enheder , kan en administrator bruge den samme proces, der er beskrevet ovenfor, og tildele disse enheder til en bestemt adresse eller en mere præcis placering inde i adressen (som et gulv eller et rum). Under Brugeradministration i giver fanen Op kald mulighed for, at et bestemt nummer kan bruges til en bruger og dennes enheder til at få en bestemt afsendelsesadresse. Følgende billeder illustrerer, hvordan et bestemt nummer kan tildeles en enhed. Administratoren er ansvarlig for at sikre, at det nummer, der bruges af enheden, får tildelt den korrekte afsendelsesadresse. Adres setildelingen udføres typisk gennem PSTN-udbyderen af den pågældende placering.
Til USA-baserede telefoniinstallationer, der skal levere forbedrede nødopkald sløsninger, bruger RedSky's Horizon Mobility integreret i til nødopkaldsrouting. Når du bruger RedSky til opkaldsrouting, skal en administrator tilmelde sig en konto via Cisco og konfigurere de relevante oplysninger i Op kald -> Serviceindstillinger for at aktivere denne funktion. Når RedSky- tjenesten er aktiveret på systemniveau, aktiverer en administrator RedSky- tjenesten på hvert placeringsniveau. Aktivering af forbedret nødopkald på et sted aktiverer tjenesten for alle enheder, der er tildelt den pågældende placering. Enheder, der understøtter forbedret nødopkald, er Cisco MPP-telefoner, Cisco PhoneOS-telefoner og Ciscos.
Der er to indstillinger til aktivering af forbedret nødopkald på et sted. Til lad RedSky at modtage netværksforbindelsesoplysninger og testopkald skal bruges til at kontrollere, at RedSky-konfigurationen til enheds- og infrastrukturkortlægninger er korrekt. Denne indstilling gør det også muligt at foretage testopkald til 933 for at udføre placerings bekræftelse ved hjælp af RedSkys IVR-system til at aflæse placeringen af den, der ringer op. Selvom dette dokument ikke dækker RedSky-konfigurationen til placeringssporing, skal en administrator ALTID teste deres placeringsopdagelse inden aktivering af nødop kald for at rute til RedSky. Når testen er afsluttet og verificeret som nøjagtig, dirigerer administratoren opkald til RedSky ved at skifte rutens nødopkald til RedSky. Denne skift dirigerer alle nødopkald til placeringen til RedSky til levering til telefonsvareren for placeringen.
Indstillingerne for udvidede nødopkald gælder også for klienter både lokalt og eksternt. Når det er lokalt, kan det spores på samme måde, som skrivebordstelefoner spores. Når brugeren er uden for det lokale miljø, vil brugeren være i stand til at indstille sin placering dynamisk direkte i. Du kan finde flere oplysninger om nødopkald under Ud videt nødopkald til.
Licensering
Der er flere muligheder for at tildele licenser til brugere.
Manuel tildeling gennem
Administratorer tildeler licenser manuelt til individuelle brugere via grænsefladen.
Administratorer kan redigere servicelicenser for individuelle brugere og tildele opkaldslicenser direkte.
Automatiske licenstildelingsskabeloner
Brug licenstildelingsskabeloner til automatisk at tildele licenser til brugere baseret på gruppe- eller organisationsindstillinger.
Automatisk licensering kan udføres ved hjælp af katalogsynkronisering eller manuelle brugeropdateringer, men brugerne skal have et gyldigt +E.164-formateret telefonnummer, og telefonnumrene skal findes på et sted inden brugerklargøring. Hvis betingelserne ikke er opfyldt (f.eks. ugyldigt telefonnummer format), vil licenser ikke blive tildelt.
Massetildeling via CSV-skabelon
Upload en CSV-fil med brugeroplysninger og licenstildelinger for at tilføje eller ændre flere brugere på én gang.
CSV-import understøtter tilføjelse af op til 20.000 brugere og tildeling af licenser, men licenser kræver specifikke felter som telefonnummer og udvidelse.
API-baseret tildeling
Brug API'er til programmatisk at tildele licenser og administrere brugere.
understøtter API-operationer til bruger- og licensadministration (People, SCIM 2.0 og Licenses API'er), som kan udnyttes til automatisering af licenstildeling. License- API'en tillader samtidig tildeling af licenser, telefonnumre og udvidelser.
| Tildelingsmetode | Fordele | Ulemper |
|---|---|---|
| Manuel gennem | Enkelt for få brugere. Tillader præcis og detaljeret kontrol over licenstildeling. | Ikke skalerbar, tidskrævende Tilbøjelig for menneskelige fejl under manuel indtastning. |
| Automatiske licensskabeloner | Skalerbar Reducerer manuelle fejl Kan anvendes på nye og eksisterende brugere. | Kræver gyldige telefonnumre og placeringer. Mere kompliceret at op sætte Kræver også brugergrupper pr. gruppe af brugere med tilsvarende licenskrav. |
| Masseoverførsel af CSV | Effektiv til store brugersæt Tillader samtidig tildeling af licenser, telefonnumre og udvidelser. | Kræver omhyggelig CSV-formatering Potentiale for fejl, hvis telefon numre eller udvidelser mangler eller er forkerte. |
| API-baseret tildeling | Automatiserbar, fleksibel. Tillader samtidig tildeling af licenser, telefonnumre og udvidelser. | Kræver udvikling og API viden. |
Tabellen Brugerklargøringsindstillinger - resumé opsummerer brugerklargøringsindstillinger og deres fordele og ulemper. Denne oversigt hjælper med at vælge den bedste licenstildelingsmetode baseret på kundens organisationsstørrelse, automatiseringsfunktioner og brugerklargørings processer og krav.
Hvor det er muligt, anbefaler Cisco at tildele opkaldslicenser ved hjælp af licensskabeloner. Dette kræver, at for hver gruppe af brugere, der kræver et unikt sæt licenser (Eksempel - Standard vs. Professionel) eksisterer en gruppe med de respektive gruppemedlemskaber. Som beskrevet i afsnittene Brugergrupper kan brugergrupper defineres manuelt i eller synkroniseres fra en virksomhedsmappe. En kombination af begge tilgange er mulig.
Brugere, der tilhører flere grupper, får licenser fra alle opgaver, der anvendes på alle deres grupper. Dette gør det muligt at bruge licensspecifikke sikkerhedsgrupper i virksomhedsmappen til at administrere licenstildeling, hvor den resulterende brugerlicenstildeling styres af foreningen af gruppemedlemskaber.
Du kan finde flere oplysninger under Konfigurere automatiske licenstildelinger i Control Hub og Konfigurere skabeloner til automatisk licenstildeling til Webex Calling brugere.
Licenskrav
Dette afsnit dækker kun relaterede licenser. Andre licenstyper (Eksempel - Webex-enhedsregistrering, meddelelser, møder) er ikke dækket. Som en del af designprocessen skal licenskravene fastlægges. Licenstællinger for følgende licenstyper skal beregnes:
-
Standard: antal individuelle brugere, der kræver standardtelefonfunktioner.
-
Profession el: antal brugere og arbejdsområder, der kræver avancerede telefon funktioner. Virtuelle linjer og gruppe voicemail har ret til et forhold på 1:1 for hver professionel licens. I sjældne tilfælde, hvor antallet af krævede virtuelle linjer eller gruppebeskeder overstiger antallet af brugere og arbejdsområder, der kræver avancerede telefonif unktioner, skal der tages højde for yderligere professionelle licenser.
-
Arbejdsområde til fællesområde: antal fælles brug eller fællesarealer, der kræver standardopkaldsfunktioner.
-
Kundeservice: antal agenter og vejledere, der kræver Customer Assist-funktioner. Kundeservice inkluderer Professional-licensen.
-
Rutelistek ald: antal krævede Cloud Connected PSTN-opkald mellem lokale brugere og/eller specialiserede tredjepartsprogrammer i det lokale miljø.
-
Attendant Console: antal brugere, der har brug for adgang til den ledsagende konsolklient.
-
Cisco-opkaldsplan (udgående opkaldsplan): antal brugere, der har brug for et PSTN- nummer og/eller adgang til udgående PSTN-opkald til Cisco PSTN-tjenesten.
Der er ingen dedikeret licenstype til professionelle arbejdsområder. Professionelle arbejdsområder bruger en Professional-licens.
Arbejdsområder, der kun er Hot-desk, tilbyder hot-desking-værtstjenesten og nødopkald fra hot-desking-værten og kræver ingen licens. Du kan finde flere oplysninger i Tilføj og administrere enheder, der kun fungerer som hot desk.
Hvis du vil bestemme den krævede licenstype for hver bruger og arbejdsområde baseret på de nødvendige funktioner, skal du se Funktioner, der er tilgængelige efter licenstype for Webex Calling.
For at skelne mellem funktionalitet, der tilbydes af opkaldskøer kombineret med den professionelle licens i modsætning til kundeservice, se sammenligning af op Webex Calling kald skø og kundeassistentfunktioner.
Brugerklargøring
Når du klargør brugere i Webex, er der flere tilgængelige muligheder, der hver især passer til forskellige organisatoriske behov og miljøer:
-
Manuel klargøring: Administratorer kan tilføje og administrere individuelle brugere direkte indeni. Denne metode er ligetil, men bedst egnet til små organisationer eller begrænsede bruger ændringer.
-
Masseklarering via CSV: For større brugerbaser kan administratorer importere og opdatere brugere i bulk ved at uploade CSV-filer til. Dette muliggør effektiv styring af op til tusindvis af brugere på én gang.
-
Indstillinger for mappesynkronisering:
Directory Connector: Dette er et automatisk synkroniseringsværktøj, der bruges i Microsoft Active Directory miljøer. Det synkroniserer brugerkonti, grupper og attributter på en planlagt basis (time, dagligt eller ugentligt). Det understøtter multi-domæne og multi-forest Active Directory opsætninger og kan synkronisere profilbilleder og rumobjekter.
Guide@@ appen Entra ID (Azure AD): Denne metode er designet til organisationer, der bruger Microsoft Entra ID (Azure AD) og giver automatisk synkronisering i næsten realtid af bruger konti og attributter direkte fra Entra ID til. Det er fuldt administreret indeni og kræver minimal opsætning.
SCIM 2.0-applikationer: For ikke-Microsoft-miljøer eller andre identitetsudbydere som Okta eller Duo muliggør SCIM-baserede synkroniseringsapps automatisk brugerklargøring og afklaring med attributkortlægning og gruppesyn kronisering.
-
Unified CMbrugersynkronisering: Denne indstilling gør det muligt at oprette brugerkonti baseret på eksisterende slutbrugere ved at synkronisere fra til. Dette kræver, at Cloud Connected UC (CCUC) kører på klyngerne i det lokale miljø. Det anbefales dog generelt at synkronisere brugere fra et centraliseret skybibliotek som Entra ID snarere end direkte fra.
-
API-klargøring: Offentlige API'er (People, SCIM 2.0) kan bruges til at klarlægge brugere. Den største fordel ved at bruge API'er er muligheden for at integrere brugerprovisionering med andre virksomhedssystemer.
Denne oversigt og tabel afspejler de vigtigste brugerklargøringsindstillinger, deres fordele og begrænsninger for at hjælpe dig med at vælge den bedste tilgang til din organisations behov.Tabel 6. Brugerklargøringsindstillinger for Tilvejebringelsesmetode Beskrivelse Fordele Ulemper Håndbog Opret/administrere brugere individuelt i Enkel for få brugere; ingen infrastruktur nødvendig Ikke skalerbar; tidskrævende for mange brugere Bulk (CSV-fil) Importer/opdater brugere i bulk via CSV i Effektiv for grupper; ingen kodning påkrævet Manuel CSV-forberedelse; mindre dynamisk Mennesker og SCIM 2.0 API Programmatisk brugeradministration via Webex API'er Fleksibel; understøtter automatisering og integration Kræver udvikling og infrastruktur Katalogsynkronisering Automatisk synkronisering fra AD, Entra ID, SCIM apps, Unified CM Automatiserer livscyklus; understøtter filtrering og kortlægning Opsætningskompleksitet: nogle af mulighederne har begrænsede funktioner eller kræver infrastruktur
Brugergrupper
Administration af brugergrupper i giver administratorer mulighed for at organisere brugere i grupper for effektiv massestyring af licenser, indstillinger, og ressourcer. Grupper hjælper med at strømline administrationen ved at anvende politikker, licenser og indstillingsskabeloner på flere brugere samtidigt i stedet for at administrere brugere individuelt.
Brugergruppestyring giver flere fordele, herunder:
-
Forenklet administration: Administrer licenser, indstillinger og politikker for flere brugere på én gang.
-
Konsist ens: Anvend ensartede indstillinger og licenser på tværs af brugere i samme gruppe.
-
Skalerbarhed: Understøtter op til 250.000 medlemmer pr. Gruppe.
-
Integration: Synkroniser grupper fra Microsoft Entra ID (Azure AD) eller Active Directory til automatiseret bruger- og gruppeadministration.
-
Fleksibilitet: Opret lokale grupper eller synkroniser sikkerhedsgrupper; administrer grupp emedlemskab manuelt eller via CSV-filer.
-
Ressourceallokering: Styr adgangen til integrerede apps og tjenester baseret på gruppemedlemskab.
De vigtigste anvendelsestilfælde for brugergrupper ved klargøring er:
-
Licenstildel inger: Tildel licenser til grupper for automatisk at levere tjenester som opkald, møder, beskeder eller hybridtjenester til gruppemedlemmer.
-
Indstillingsskabeloner: Anvend samlinger af serviceindstillinger (f.eks. beskeder, møde, opkald) på grupper for at opnå ensartet brugeroplevelse.
-
Hånd@@ tering af massebrugere: Tilføj eller fjern brugere i bulk via CSV-filer eller mappesyn kronisering.
-
Automatisering og integration: Brug API'er eller mappesynkronisering til automatiseret bruger- og gruppens livscyklusstyring.
Følgende tabel opsummerer de forskellige muligheder for at administrere brugergrupper og gruppe administration i.
| Mulighed | Beskrivelse | Fordele | Ulemper |
|---|---|---|---|
| gruppetildeling (grupper) | Opret og administrer grupper direkte i. Tilføj/fjern medlemmer manuelt eller via CSV. | Fuld kontrol over gruppemedlemskab Umiddelbar anvendelse af licenser og skabeloner Let at oprette og redigere grupper |
Manuelle opdateringer kræves Risiko for fejl i manuelle CSV-uploads Ingen automatisk synkronisering med eksterne mapper |
| Synkroniserede grupper fra Entra ID (Azure AD) eller Active Directory | Synkroniser automatisk sikkerhedsgrupper og medlemskaber fra eksterne katalog tjenester. | Automatiseret synkronisering reducerer manuelt arbejde Sikrer overensstemmelse med virksomhedsfortegnelsen Støtter store organisationer |
Kan ikke redigere gruppemedlemskab i Synkroniseringsforsinkelse op til 12 timer Indlejrede grupper kræver manuel markering |
| Grupper og SCIM 2.0 API (grupper) | Brug Grupper eller SCIM 2.0 API til programmatisk gruppe- og medlemsstyring | Automatisering og integration med andre systemer Skalerbar til store eller komplekse miljøer |
Kræver udviklingsindsats Kompleksitet afhænger af API-brug |
Mens synkroniserede grupper sikrer konsistens og tilbyder et enkelt administrationspunkt, er en hybrid tilgang, der kombinerer synkroniserede grupper og grupper (enten administreret i kontrolhub eller via API'er) mulig. Så for eksempel kan grupper til licenstildeling være synkroniserede grupper, og et separat sæt grupper kan bruges til at tildele bruger- og opkaldsskabeloner.
Denne omfattende tilgang til administration af brugergrupper gør det muligt for organisationer effektivt at administrere brugerlicenser, indstillinger, og politikker, hvilket sikrer ensartede og skalerbare samarbejdsoplevelser.
Anbefalet tilgang, når du migrerer fra til
Den primære datakilde for brugere på er databasen, som indeholder slutbrugeroplysninger. Imidlertid, er typisk ikke den autoritative kilde til brugeridentitetsstyring og endnu vigtigere vil blive lukket ned ved afslutningen af overgangen og udelukkes derfor som langsigtet autoritativ kilde til identitetsoplysninger.
Cisco anbefaler at bruge et centraliseret cloudbibliotek som Microsoft Entra ID (Azure AD) som den eneste kilde til sandhed for brugeridentiteter. Synkronisering af brugere fra Entra ID for at sikre konsistens, forenkle administrationen og understøtter Single Sign-on (SSO) funktioner.
For at sikre, at alle brugere på også er til stede i Entra ID, skal organisationer kontrollere, at brugerkontiene i svarer til konti i Entra ID. Dette kan gøres ved at eksportere brugerlister fra og sammenligne dem med Entra ID-brugerlister.
Sammenfattende er den anbefalede klargøringsmetode at synkronisere brugere fra Microsoft Entra ID (Azure AD) til Webex ved hjælp af Azure AD Wizard eller SCIM-apps. Manuel og CSV-masseklarering er tilgængelig som supplerende metoder, men er mindre skalerbar og mere fejltilbøjelig til store organisationer. At sikre, at Entra ID er den autoritative kilde, og at alle brugere findes i Entra ID, er afgørende for en vellykket migrering og ensartet bruger oplevelse på tværs af miljøer.
Overgangen fra en katalogtjeneste i det lokale miljøActive Directory, f.eks. til en cloudkatalogtjeneste, f.eks. Entra ID (Azure ID), er uafhængig af opkaldsovergangen. Cisco anbefaler, at overgangen til en cloud-katalogtjeneste afsluttes, inden opkaldsover gangen påbegyndes.
Design af brugergrupper
Efter overgangen til virksomhedsmappen fra det lokale miljø til skyen skal du indsamle de nødvendige brugergrupper, der er drevet af licens- og funktions skabelonkrav. For hvert gruppedokument:
-
Gruppenavn: entydigt navn på gruppen.
-
Licenser: licenser, der skal tildeles denne gruppe (hvis nogen) og omfang (skal licenser tildeles eksisterende brugere eller kun til nye brugere)
-
Indstillingsskabeloner: Webex App- og Brugeropkaldsskabeloner.
-
Katalogsynkronisering: Synkroniseres denne gruppe fra virksomhedsmappen, eller er dette en lokal Webex-gruppe klargjort i Control Hub eller via en API.
-
Beskrivelse: hvordan vil denne gruppe blive brugt, og hvilke brugere der skal være medlemmer af denne gruppe
Disse oplysninger vil blive brugt senere i implementeringsfasen til at oprette lokale grupper eller grupper i virksomhedsmappen og administrere bruger nes gruppemedlemskab.
Enkelt login (SSO)
Cisco anbefaler brug af SSO til brugergodkendelse. Brug af SSO har nogle overbevisende fordele, herunder:
-
Forenklet brugergodkendelse: Brugere kan logge på én gang ved hjælp af deres virksomhed soplysninger (f.eks. fra Azure ID) for at få adgang til og andre integrerede programmer, hvilket eliminerer behovet for flere adgangskoder og reducerer loginbeskeder. Dette forbedrer sikkerheden ved at sikre, at virksomhedsadgangskoder aldrig gemmes eller overføres til efter godkendelse.
-
Forenklet brugeradministration: Automatiserer oprettelse, opdateringer og deaktivering af brugerkonti baseret på ændringer i virksomhedsmappen, reducerer administrative omkostninger og sikrer, at kun autoriserede brugere har adgang.
-
Forbedret sikkerhed: SS O reducerer adgangskodetræthed og risikoen for adgangskoderelaterede brud ved at centralisere godkendelse via betroede identitetsudbydere (IDP'er).
-
Nem integration af multifaktor-godkendelse (MFA): MFA kan nemt understøttes enten gennem en Identity Access Management-løsning som Cisco Duo eller gennem MF A-understøttelse af IdP.
Der er flere muligheder for at implementere SSO for tjenester:
-
SAML 2.0-baseret SSO: Den primære protokol, der understøttes til SSO-integration, muliggør sikker udveksling af godkendelsesoplysninger mellem Id P'en og tjenesteudbyderen.
-
OpenID connect (OIDC): Under støttes som en alternativ moderne godkendelsesprotokol til SSO-integration.
-
Webex-identitet: Under støttes også som en identitetsudbyderindstilling.
SSO konfigureres og administreres centralt igennem, hvilket kræver udveksling af metadata mellem og den valgte IdP.
Efter konfiguration kan SSO testes inden for aktivering for at sikre korrekt opsætning.
Cisco understøtter integration med flere testede og almindeligt anvendte IDP'er og IAM (Identi ty Management Systems), herunder, men ikke begrænset til:
-
Cisco Duo
-
Okta
-
Microsoft Active DirectoryFøderationstjenester (ADFS)
-
Microsoft Azure
-
Ping Federate
-
OpenAM
-
F5 BIG-IP.
Disse IDP'er overholder SAML 2.0- eller OpenID Connect-standarderne og er blevet valideret for kompatibilitet med Ciscos samarbejdsløsninger.
Understøttelse af flere IdP
giver organisationer mulighed for at konfigurere SSO med flere IDP'er til at imødekomme komplekse it- miljøer såsom fusioner, opkøb eller decentrale it-afdelinger, hvor forskellige grupper bruger forskellige IDP'er. Understøttelse af flere IdP kan enten implementeres ved hjælp af Multi ple IdP-funktionen i eller gennem integration af et virksomheds-IAM-system som Cisco Duo.
Understøttelsen af flere identitetsudbydere (IdP) adresserer flere vigtige brugssager, hvor organisationer kræver fleksibel og sikker godkendelse på tværs af forskellige it-miljøer:
1. Fusioner og opkøb
Når virksomheder fusionerer eller erhverver andre, har de ofte separate it-infrastrukturer og særskilte IDP'er, der ikke kan forene sig. Flere IdP-understøttelser giver brugere fra begge organisationer mulighed for at godkende og samarbejde sikkert uden at skulle forene deres identitetssystemer med det samme.
2. Flere uafhængige it-afdelinger
Store organisationer eller offentlige institutioner kan have flere uafhængige it-afdelinger, der hver administrerer deres egen IdP. Flere IdP-funktioner gør det muligt for disse afdelinger at vedligeholde deres egne godkendelses systemer, samtidig med at brugerne får adgang problemfrit.
3. Forskellige brugergrupper eller domæner
Organisationer med forskellige brugergrupper (f.eks. medarbejdere vs. entreprenører) eller flere e-mail- domæner kan konfigurere routingregler til at dirigere godkendelsesanmodninger til den relevante IdP baseret på domæne- eller gruppemedlemskab. Dette understøtter differentierede adgangspolitikker og sikkerhed skontroller.
4. Understøttelse af forskellige godkendelsesprotokoller
understøtter SAML- og OpenID Connect (OIDC) IDP'er, så organisationer kan integrere forskellige typer identitetsudbydere i henhold til deres eksisterende infrastruktur og sikkerhedskrav.
5. Forbedret sikkerhed og overholdelse
Ved at aktivere flere IDP'er kan organisationer implementere stærkere godkendelsesmekanismer, herunder multifaktorgodkendelse (MFA) gennem integrationer som Duo, og håndhæve ensartede sikkerhedspolitikker på tværs af forskellige brugerbaser.
6. Forenklet brugeroplevelse
Brugere kan autentificere ved hjælp af deres eksisterende legitimationsoplysninger fra deres respektive IDP'er, hvilket giver en samlet logonoplevelse på trods af den underliggende kompleksitet i flere identitetssystemer.
Mens flere IdP-understøttelser giver fleksibilitet, kræver det omhyggelig koordinering mellem sikkerheds- og identitetsteams for at opretholde ensartede sikkerhedspolitikker og undgå potentielle sårbarheder.
Duo MFA med SSO til
Duo Access Gateway (DAG) kan godkende brugere ved hjælp af eksisterende lokale eller skybaserede mapper som f.eks. Active Directory (AD) og OpenLDAP. Det understøtter også integration med andre identitetsudbydere som Microsoft ADFS, Microsoft Azure, Okta, OneLogin, CAS og Shibboleth. Denne fleksibilitet giver organisationer mulighed for at bruge deres nuværende katalog infrastruktur til Webex SSO med Duo MFA.
Duo fungerer som et stærkt godkendelseslag oven på den primære mappegodkendelse. Det fungerer som en identitetsudbyder (IdP) ved hjælp af SAML 2.0 til at håndhæve tofaktorautentificering (2FA), før der gives adgang til. Duo evaluerer bruger-, enheds- og netværkskontekst i forhold til konfigurerbare politikker for at tillade eller nægte adgang, hvilket forbedrer sikkerheden ud over blot brugernavn og adgangskode. Duo giver også fleksible politikkontroller, såsom at kræve MFA ved hvert login for nogle apps og sjældnere for andre.
Fordelene ved Cisco Duo omfatter:
-
Forbedret sikkerhed: Tilfø jer phishing-resistent MFA for at beskytte adgangen, hvilket reducerer risikoen for kompromitterede adgangskoder.
-
Fleksible politikker: Tillader detaljeret kontrol over godkendelseskrav pr. program eller brugergruppe.
-
Integration med eksisterende mapper: Under støtter lokal AD, OpenLDAP, cloud- mapper og forskellige SSO-udbydere, hvilket minimerer infrastrukturændringer.
-
Brugervenlighed: Under støtter Single Sign-On (SSO) for at reducere adgangskodetræthed ved at give brugerne mulighed for at logge ind én gang og få adgang til flere ressourcer sikkert.
-
Pålidelige slutpunkter: Under støtter enhedstillidelighed for klienter på Windows og macOS, hvilket forbedrer sikkerhedsstillingen.
-
Selvbetjeningstilmelding: Inline-tilmelding og duo-prompt forbedrer brugeroplevelsen under MFA-opsætning.
Duo MFA med SSO til udnytter eksisterende mapper som Active Directory og OpenLDAP, eller cloud-identitetsudby dere, til at godkende brugere. Duos rolle er at levere en stærk, politikdrevet anden godkendelses faktor integreret gennem SAML 2.0, hvilket forbedrer sikkerheden, samtidig med at brugervenligheden opretholdes gennem SSO. Fordelene inkluderer forbedret sikkerhedsstilling, fleksibel politikh åndhævelse, problemfri integration og en bedre brugeroplevelse.
Cisco anbefaler implementering af SSO for brugere. For forbedret sikkerhed anbefales integration med Cisco Duo.
Enterprise IAM- og SSO-strategien bør implementeres, inden overgangen fra til påbegyndes.
Funktioner
har et komplet komplement af kernefunktioner, der er inkluderet i tjenesten. Dette inkluderer mange opkaldsfunktioner i virksomhedsklasse, der har været tilgængelige i mange år. Du kan muligvis ikke se 100% paritet mellem funktioner og funktioner, men som du kan se i nedenstående figur, er de vigtigste opkaldsfunktioner tilgængelige i.
Udover de mange brugerfunktioner, har kernesystemfunktioner, der er inkluderet i platformen. Disse inkluderer funktioner som autoledsagere, opkaldskøer, opkaldspark osv. Du kan se alle de tilgængelige kernesystem funktioner under Service → Opkald → Funktioner som vist i figur Webex Callingkerne funktioner.
Automatisk ledsager
Auto Attendant giver mulighed for 24/7 automatisering af håndtering af indgående opkald, hvilket giver mulighed for effektiv opkaldshåndtering uden behov for, at en person besvarer hvert opkald.
Den automatiske ledsager besvarer indgående opkald og giver den, der ringer op, en menu med muligheder for, hvor de vil dirigere deres opkald. Dette kan være til en person, en telefonsvarerboks eller en opkaldstjeneste (f.eks. Opkaldskø). Den, der ringer op, bruger telefonens opkaldstastatur til at indtaste nummeret fra menuen Auto Attendant.
Den automatiske svartjeneste understøtter følgende nøglefunktioner:
-
Forretnings- og efterarbejdsplaner
-
Ferieplan
-
Opkaldsmenuindstilling for at dirigere dine kunder derhen, hvor de skal hen
-
Tilpas hilsner
-
Opkald efter navn
-
Muligheder for viderestilling af opkald
-
Control Hub analyser og rapporter.
Du kan finde flere oplysninger i Administrer automatiske besvarelser.
Ring til Park
Call park giver brugerne mulighed for nemt at sætte et opkald på vent, så en anden bruger nemt kan hente, når de er tilgængelige til at tage det. Det frigør også den bruger, der besvarede det oprindelige opkald, til at foretage eller modtage andre opkald, mens opkaldet er parkeret.
Der er to typer opkaldsparker tilgængelige i:
-
Call park direct - gør det muligt for enhver bruger at parkere et opkald til en anden brugers udvidelse eller til en opkaldspark-udvidelse, som defineret af administratoren
-
Call park group - giver en defineret gruppe brugere mulighed for automatisk at parkere opkald mod tilgængelige parkdestinationer, der er defineret for gruppen. Disse destinationer kan være gruppemedlemmernes udvidelser eller udvidelser af opkaldsparker.
Baseret på konfiguration og parkeringstype kan brugerne hente opkald ved at <extension of parked call>ringe til *88+>, trykke på linjetasten, der er knyttet til opkaldsparkens udvidelse, eller bruge en softkey på deres IP-adresse.
En tilbagekaldelsesmulighed er tilgængelig for at tilbagekalde et parkeret opkald efter en bestemt periode til den bruger, der parkerede opkaldet, eller til en alternativ bruger.
Du kan finde flere oplysninger i Administrer opkaldsparkering i Control Hub.
Afhentning af opkald
Optagelse af opkald giver en administrator mulighed for at definere en gruppe brugere (medlemmer), der kan besvare et opkald til et andet medlems telefon. Dette giver en bruger mulighed for at besvare opkald, når deres holdkammerater har travlt og ikke kan besvare et indgående opkald.
Brugerne i en gruppe skal være på samme sted.
Brugere kan bruge enten skrivebordstelefonen eller deres skrivebordstelefon til at afhente et opkald.
-
:
-
Understøtter visuelle og lydmeddelelser
-
Meddelelse om indgående opkald
-
FAC-baseret (opkald*98) eller afhentning af opkald med notifikationer
-
Meddelelser om afhentning af opkald til multiline.
-
-
Skrivebordstelefoner:
-
Meddelelse om indgående opkald
-
Lyd klokkeslæt og visuel meddelelse gennem håndsættets LED. 6821 understøtter kun lydklokkeslæt
-
Når meddelelsestypen er valgt i er ikke ingen
-
-
Meddelelser om afhentning af opkald kun for primære linjer.
-
Du kan finde flere oplysninger i Konfigurere gruppe for afhentning af opkald.
Opkaldskø
inkluderer kun taleopkaldskøer som en del af kernefunktionerne, og enhver bruger med en Professional-licens kan være en del af en opkaldskø, agent eller supervisor. Denne funktion giver brugerne mulighed for effektivt at interagere med kunderne. Opkaldskøer understøtter en delmængde af nogle af callcen ter-kernefunktionerne som stemmekøer, tilbagekald, færdigheds- eller prioritetsrouting, agentkø styring, analyse, rapportering osv.
Ciscos opfordring til Microsoft Teams-integration giver agenter adgang til opkald og funktioner i opkaldskøen direkte fra deres Microsoft Teams-klient.
Opkaldskøer understøtter følgende nøglefunktioner:
-
Hilsner og beskeder (velkomst, komfort, hvisken osv.)
-
Hold musik
-
Tilbagekald
-
Politikker for køruting (natservice, helligdage, videresendelse)
-
Login/log ud af agentkøen
-
Administration af agentkøstatus
-
eller Desk Telefonsupport
-
Supervisor-agent overvåger, træner, pramme eller overtager via Feature Access Codes (FAC'er)
-
(administratoradgang) til:
-
køstyring
-
Agent- og køanalyse og rapportering
-
Kø-, agent- og vejlederstyring.
-
Du kan finde flere oplysninger i Konfigurere opkald skø.
har en tilføjelsesfunktion til kundeservice, der giver yderligere opkaldskøfunktioner og giver agenter og vejledere en bedre brugeroplevelse inden for. For en sammenligning af funktionerne Opkaldskø og Kundeservice, se Sammenligning af Webex Calling op kaldskø og kundeassistent funktioner.
Jagtgruppe
Hunt Groups giver mulighed for routing af indgående opkald til en bestemt gruppe af brugere gennem et forudbestemt opkaldsroutingsmønster. Dette sikrer, at opkald besvares af den rigtige gruppe af brugere eller sendes til en voicemail til opfølgning.
En stor forskel mellem Hunt Groups og Call Queues er, at opkald ikke står i kø i en jagt gruppe, så hvis ingen brugere i Hunt-gruppen er tilgængelige til at besvare opkaldet, vil det blive afbrudt, sendt til telefonsvarer eller videresendt til et andet nummer (bruger eller tjeneste).
Du kan finde flere oplysninger i Administrer jagtgrupper i Control Hub.
Driftstilstande
Funktionen Operating Modes giver virksomheder mulighed for effektivt at dirigere opkald til forskellige destinationer (brugere, telefonsvarer, opkaldstjenester som en opkaldskø). Hvor og hvornår et opkald dirigeres, er baseret på en tids plan for dagen og ugedagene, og enhver bruger kan bemyndiges til at administrere disse tilstande (tidsplaner) for at kontrollere ændringer i opkaldsrutingen.
Som et eksempel kan opkald til en opkaldskø dirigeres til en anden opkaldskø med agenter i en anden tidszone for at besvare opkald efter åbningstider, i løbet af arbejdstiden dirigeres til de lokale agenter og i ferier dirigeres til telefonsvarer til op følgning, når agenterne vender tilbage til kontoret.
En autoriseret bruger kan skifte mellem disse forskellige videresendelsesscenarier (tilstande), hvis de har brug for at ændre, hvor indgående opkald dirigeres i en bestemt periode. Disse brugere kan administrere tilstand ene gennem deres 6800/7800/8800 MPP-telefoner, 9800-telefoner eller i User Hub under Administrer tilstande.
Du kan finde flere oplysninger i Op kaldsdirigering baseret på driftstilstande i Webex Calling.
Personsøgningsgruppe
Personsøgningsgrupper giver brugerne mulighed for at foretage et envejsopkald for at sende en lydbesked til en gruppe brugere. Hver gruppe kan indeholde op til 75 målbrugere og/eller arbejdsområder, der nås ved at ringe til et foruddefineret nummer eller en udvidelse.
Når en bruger ringer til en personsøgningsgruppe, foretages der et samtidig opkald til alle de tildelte mål i gruppen, hvor den, der ringer op, kan tale deres beskeder og lægge på, når de er færdige.
Du kan finde flere oplysninger i Konfigurere en personsøgningsgruppe i Control Hub.
Optagelser
understøtter optagelse af opkald foretaget eller modtaget af en bruger. Dette kan være nødvendigt af hensyn til kvalitets-, sikrings-, sikkerheds- eller uddannelsesbehov. Som standard optages opkald i, men andre tredjeparts optagelsesudbydere kan også bruges, hvis andre optagef unktioner eller overholdelse og lovkrav er påkrævet.
Når du bruger som optagelsesplatform, administreres alle optagede opkald indeni. Fuldstændige administratorer med rollen som Compliance Officer kan spille og downloade optagelserne. Uden rollen som Compliance Officer kan administratoren kun slette optagelserne.
Du kan finde flere oplysninger om denne funktion og en liste over tredjepartsoptagelser under Administrer opkalds optagelse for Webex Calling.
Enkelt nummerrækkevidde
Enkeltnummerrækkevidde tillader opkald til en brugers telefonnummer for at ringe til flere enheder. Dette kan omfatte andre skrivebordstelefoner såvel som mobiltelefoner. Opkald kan også foretages fra disse enheder, og brugerne kan skubbe og trække opkald mellem dem.
Du kan finde flere oplysninger om denne funktion, og hvordan en administrator konfigurerer den i, under Konfigurere enkeltnummerrækkevidde (kontor hvor som helst).
Du kan finde flere oplysninger om, hvordan en bruger kan administrere og konfigurere denne funktion for sig selv i Webex User Hub (portalen), under Konfigurere enkeltnummerrække vidde (kontor hvor som helst).
Voicemail-gruppe
Voicemail-grupper giver mulighed for en delt voicemail-boks, der kan tildeles en bruger eller opkaldsroutingsfunktion. Nogle af grundene til, at en voicemail-gruppe kan være påkrævet, er:
-
Generel telefonsvarer til en afdeling eller arbejdsgruppe
-
Føj mulighed for voicemail til en automatisk ledsager eller jagtgruppe
-
Sådan sender du overløbsopkald fra en opkaldskø
-
Brugere, der kun har brug for en voicemail-boks.
Du kan finde flere oplysninger i Administrer en delt telefonsvarer og indgående fax boks for. Webex Calling
Attendant Console vises på siden Opkaldsfunktioner i Webex, men det er en tilføjelsesfunktion, der kræver køb af den ledsagende konsol licens for at bruge.
Du kan finde flere oplysninger i Kom godt i gang med Attendant Console.
Du kan finde oplysninger om alle funktioner, herunder nogle tilføjelsesfunktioner, under Funktioner, der er tilgængelige efter licenstype for Webex Calling.
Implementere
Netværksberedskab
Det første skridt i overgangen til er at sikre pålidelig og sikker internetforbindelse mellem det lokale netværk og skyen.
Da de fleste organisationer opretter forbindelse til internettet via en eller flere firewalls eller sikkerhedsenheder, er det vigtigt at validere, at de krævede trafikstrømme under støttes.
Netværks- og sikkerhedsadministratorer skal forstå disse strømme med hensyn til:
-
Retning (indgående vs udgående)
-
Protokoller (Eksempel - SIP TLS, SRTP, HTTPS)
-
IP-adresseintervaller, der bruges af tjenester
-
Portnumre, der skal åbnes eller tillades.
Dette sikrer, at virksomhedens firewalls, NAT-enheder og anden netværksinfrastruktur er korrekt konfigureret til at imødekomme trafik, samtidig med at virksomhedens sikkerhedspolitikker opretholdes.
For oplysninger om de krævede strømme, herunder IP-adresse, porte, og protokoller, se Portreferenceoplysninger for Webex Calling. Brug disse oplysninger til at konfigurere firewall, proxyer og anden netværksinfrastruktur i den eksisterende installation for at aktivere netværksstrømme.
Decentraliseret internetudbrud fra hver filial eller websted er den anbefalede tilgang til cloud-samarbejdstjenester såsom. Ved at tillade trafik at afslutte lokalt, kan denne model:
-
Reducerer forsinkelse og jitter tur/retur, hvilket forbedrer den samlede opkaldskvalitet
-
Skalerer effektivt, efterhånden som flere brugere og websteder overgår til
-
Fungerer problemfrit med SD-WAN, som dynamisk kan dirigere sessioner til det nærmeste cloud-indgangspunkt for optimal ydeevne
- Tillader at spore brugerplacering baseret på deres offentlige IP-adresse, hvilket hjælper med mediesti analyse og fejlfinding.
Derudover skal organisationer sikre tilstrækkelig internetbåndbredde på hvert websted. Bå ndbredde skal dimensioneres baseret på det forventede antal samtidige opkald, den valgte codec (f.eks. Opus eller G.711) plus overhead til signalering, retransmissioner og vækst. Dette stemmer overens med forberedelsesfasen i PPDIO-livscyklussen og skaber et solidt fundament for migration.
Indledende opsætning
Det indledende opsætningsunderafsnit inden for implementeringsfasen af implementering er grundlæggende for etablering af et velstruktureret og håndterbart cloud-opkaldsmiljø. Denne fase omfatter kritiske opgaver såsom opsætning af organisationen, indkøb og tildeling af licenser og verifikation og krav på din virksomheds domæner for at sikre korrekt brugeradministration og sikkerhed. Derudover inkluderer den klargøringslic ensskabeloner til automatisering af brugerlicenstildelinger, konfiguration af Single Sign-On (SSO) for at strømline brugergodkendelse og forbedre sikkerheden og justere service- og klientindstillinger, så de passer til organisationens politikker og brugerbehov. Gennemførelsen af disse indledende konfiguration saktiviteter sikrer, at miljøet er korrekt konfigureret til skalerbarhed, sikkerhed og problemfri brugeroplevelse, hvilket sætter scenen for efterfølgende udrulnings- og driftsfaser.
Domænebekræftelse
For at gøre det muligt at identificere brugere, der er registreret med din virksomheds e-mail-domæner på, er det vigtigt at bekræfte dine domæner. Uden domænebekræftelse vil brugerne blive tildelt en forbrugerorganisation, hvilket komplicerer brugeradministration for din virksomhed. Domænebekræftelse er et obligatorisk trin, der gør det muligt for din organisation at gøre krav på og administrere disse brugere effektivt.
Sørg for, at alle domæner, der er knyttet til dine brugeres e-mail-adresser, er verificeret. Domæne bekræftelse er ikke eksklusiv; det samme domæne kan verificeres på tværs af flere organisationer.
Du kan finde flere oplysninger om administration af domæner under Administrer dine domæner.
Gør krav på (konverter) eksisterende brugere
Når du har bekræftet dine domæner, kan du fortsætte med at gøre krav på brugere, der har registreret sig for at bruge din virksomheds e-mail-domæner, i din organisation. Denne proces konsoliderer alle brugere under en enkelt organisatorisk paraply, hvilket muliggør centraliseret styring og strømlinet administration. Ved at gøre krav på disse brugere sikrer du, at din virksomhed har fuld kontrol over brugerkonti, så du kan tildele passende licenser, konfigurere tjenester og yde den nødvendige support effektivt. Denne samlede administrationsmetode forbedrer sikkerheden, forenkler brugerklargøring og sikrer ensartet adgang til tjenester på tværs af organisationen. At hævde brugere forhindrer dem også i at blive administreret i eksterne organisationer eller forbrugerorganisationer, hvorved organisatorisk integritet og kontrol over samarbejdsressourcer opretholdes.
Du kan finde flere oplysninger om, hvordan du gør krav på brugere, under Gør krav på brugere til din organisation (konverter) brugere.
Konfigurer og test katalogsynkronisering
Hvis du vil aktivere problemfri bruger- og gruppeadministration, kan du synkronisere brugere og grupper fra din virksomhedsmappe enten Microsoft Entra ID (tidligere Azure AD) eller Microsoft Active Directory (AD) til. Denne proces sikrer, at brugeridentiteter og gruppemedlemskaber konsekvent opre tholdes på tværs af dit miljø.
For organisationer, der implementerer trinvise implementeringer, er det afgørende at kontrollere og begrænse omfanget af synkronisering under indledende udrulninger. Dette minimerer risikoen for utilsigtede ændringer og giver mulighed for målrettet test inden bredere anvendelse.
Den mest effektive metode til filtrering af, hvilke brugere der synkroniseres, er at udnytte kataloggruppemedlemskab:
| 1 |
Opret en dedikeret synkroniseringsgruppe: Opret en sikkerhedsgruppe specifikt til synkronisering (f.eks. Synkroniseringsgruppe) i din virksomhedsmappe (Microsoft Entra ID eller AD). |
| 2 |
Udfyld gruppen med målbrugere: Tilføj kun de brugere, du vil synkronisere (f.eks. en testgruppe under pilotfasen) til denne gruppe. Dette giver dig mulighed for tæt at kontrollere, hvem der er inkluderet i synkroniseringsprocessen. |
| 3 |
Konfigurer synkroniseringsaftalen med gruppebaseret filtrering: Når du konfigurerer synkroniseringsaftalen i Directory Connector eller Entra ID-klargøring, skal du konfigurere omfanget til kun at omfatte brugere, der er medlemmer af den udpegede gruppe.
|
| 4 |
Udvid gruppen efter behov: Når du går videre til bredere implementeringsfaser, skal du blot tilføje yderligere brugere eller grupper til synkroniseringsgruppen. Synkroniseringsomfanget udvides automatisk til at omfatte disse brugere, hvilket giver mulighed for kontrolleret og gradvis udrulning. Eksempel på implementeringstrin:
Referencer: Synkroniser Entra ID-brugere til Control Hub |
Konfigurer og test Single Sign-On (SSO)
Single Sign-On (SSO) forbedrer sikkerheden og forenkler brugeradgangen ved at give brugerne mulighed for at godkende én gang med deres virksomhedsoplysninger og få problemfri adgang til. understøtter SSO-integration med SAML 2.0-kompatible IDP'er, herunder Microsoft Entra ID (tidligere Azure AD), Active Directory (AD) fødererede løsninger og forskellige tredjeparts-IDP'er.
På dette tidspunkt skal den designede SSO-opsætning implementeres og testes.
Referencer:
Integration af enkelt logon i kontrolhubben
konfigurere enkelt logon til webex-administration
Anskaffe, tilvejebringe og verificere licenser
Som en del af den indledende opsætning for, er det vigtigt at anskaffe, levere og verificere de relevante licenser for at aktivere og administrere tjenester effektivt. Indkøbsprocessen involverer valg af licen styper baseret på brugerroller og arbejdsbelastninger, f.eks. Professional-, Standard- og Workspace- licenser. Licenser genereres og leveres via Ciscos softwareplatforme eller gennem partnere. Efter indkøb og klargøring skal det korrekte antal licenser verificeres i. Denne proces sikrer, at organisationen har de korrekte licenser aktiveret og klar til brug i installationen.
Som en del af den indledende licensopsætning i er det vigtigt at konfigurere organisationsbaseret automatisk licensering for at strømline licenstildelingen til nye brugere. Denne opsætning gør det muligt automatisk at tildele licenser, når brugere føjes til organisationen, hvilket eliminerer behovet for manuel licens tildeling. Når du konfigurerer automatisk licensering på organisationsniveau, skal du vælge de tjenester, der skal tildeles, og definere omfanget, f.eks. anvende licenser til kun fremtidige brugere eller også inkludere eksisterende brugere.
Men hvis din installationsplan indebærer brug af automatisk licensering på gruppeniveau i stedet, kan du vælge ikke at tildele licenser på organisationsniveau for at undgå konflikter eller duplikerede licenstil delinger. Med automatisk licensering på gruppeniveau tildeles licenser baseret på gruppemedlemskab. Brugere i flere grupper modtager licenser fra alle relevante gruppetildelinger.
Gruppebaseret licenstildelingskonfiguration skal udføres, når mappesynkroniseringen er fuldført, så synkronis erede grupper findes og kan bruges til licenstildeling.
Specifikt kræver automatisk licenstildeling yderligere klareringsoplysninger såsom brugerplacering og tildeling af telefonnummer. Brugerens arbejdstelefonnummer skal være i +E.164-format, forudbestemt og tildelt en gyldig placering for at licensen kan aktiveres automatisk. Hvis disse betingelser ikke er opfyldt, vil brugeren ikke blive forsynet med tjenester automatisk og kan kræve manuel indgriben.
Sammenfattende skal du konfigurere organisationsbaseret automatisk licensering til nye brugere, hvis du vil have en bred licenstildeling for hele organisationen. Hvis du foretrækker mere detaljeret kontrol eller har forskellige licensbehov pr. gruppe, skal du konfigurere automatisk licensering på gruppeniveau og undgå at tildele licenser på organisationsniveau for at forhindre overlapning og sikre korrekt licensadministration.
Webex Calling serviceindstillinger
Det er vigtigt at foretage en omfattende gennemgang og konfiguration af de globale service indstillinger inden for.
Begynd med at få adgang til og navigere til indstillingsafsnittet. Undersøg omhyggeligt hver konfigurerbar indstilling, herunder, men ikke begrænset til, intern opkaldskonfiguration, nødopkaldsparametre, opkaldsrouting politikker, telefonsvarerstyring og enhedens standardindstillinger.
Juster disse globale indstillinger, så de afspejler organisationens politikker og designbeslutninger.
Også opsætningsindstillinger og bruger- og appskabeloner.
Pilotmigration
I implementeringsfasen repræsenterer udførelse af en pilotmigration en kritisk milepæl i valideringen af overgangen fra til. Denne pilot involverer klargøring af en repræsentativ undergruppe af brugere på tværs af en eller flere placeringer på platformen, hvilket sikrer, at den valgte population afspejler forskellige brugssager og organisatoriske roller. Parallelt med brugermigrering skal vigtige samarbejdstjenester, herunder telefonsvarer, automatiske beskeder, opkaldskøer og jagtgrupper, overføres til deres ækvivalenter for at opretholde forretningskontinuitet og servicefunktionalitet.
Pilotmigreringen skal udnytte den samme kombination af Cisco-leverede værktøjer og tredjepartsmigreringsværktøjer, som er planlagt til den bredere organisatoriske implementering, hvilket sikrer, at processer, automatiseringsarbejdsgange og integrationspunkter valideres grundigt under repræsentative forhold.
De primære mål med denne pilotudvikling er to: For det første at validere og forfine ende-til-slut-overgangsprocesserne, herunder arbejdsgange for brugerklargøring, datami greringsprocedurer og slutpunktskonfigurationer; og for det andet at verificere funktionaliteten af migrerede tjenester under virkelige driftsforhold.
Denne trinvise tilgang gør det muligt for projektteamet at identificere og afhjælpe eventuelle tekniske eller proceduremæssige problemer i et kontrolleret miljø, indsamle brugerfeedback om den nye platformsoplevelse, vurdere effektiviteten af udvalgte migreringsværktøjer og etablere tillid til migreringsm etoden, inden de fortsætter med bredere organisatorisk implementering.
Den indsigt, der er opnået i denne pilotfase, er medvirkende til at optimere efterfølgende migrationsbølger og sikre en gnidningsl øs, risikoreduceret overgang for hele virksomheden.
Køb PSTN
For at anskaffe PSTN-tjenester til, vælg først en PSTN-tilslutningsindstilling i.
Hvis en organisation planlægger at opretholde hybrid dobbelt opkaldskontrol (fase 1 i figur Trinvis opkald sovergang: Hybrid og Cloud) enten midlertidigt eller på ubestemt tid, skal de installere en eller flere lokale gateways til PSTN i det lokale miljø for at tillade opkald mellem og slutpunkter.
Hvis en fuld overgang (fase 2) til skyen er slutmålet inklusive PSTN, kræves enten en Cisco-opkaldsplan eller en Cloud Connect for mulighed for PSTN.
Arbejd med din valgte udbyder for at bestille og portere telefonnumre, før du konfigurerer dem. Bestilling af telefonnumre eller initiering af portordrer er kun krævet/muligt for PSTN og Cloud Connect i det lokale miljø for. For Cisco-opkaldsplaner startes bestilling og porting fra Control Hub, så snart placeringen er oprettet, og i lande, hvor Cisco Calling Plan er tilgængelig. Du kan finde flere oplysninger om Cisco-opkaldsplaner under Kom godt i gang med C isco-abonnementerne.
Som en del af implementeringen af PSTN skal du sikre dig, at din udbyder har aktiveret både indgående og udgående PSTN-tjenester for din placering. Derudover skal du udføre testopkald for at kontrollere, at opkald dirigeres korrekt via den valgte PSTN-forbindelse.
Konfigurer placeringer
Før du føjer brugere og enheder til, skal du angive opkaldssteder. For hver placering skal der indtastes en gyldig gad eadresse. I USA og Canada valideres denne adresse og bruges af platformen til at sende PIDF-LO-placeringsoplysninger til nødopkald.
Når du konfigurerer placeringer, der bruger PSTN i det lokale miljø, skal du konfigurere de lokale gateways i overensstemmelse hermed. I skal der oprettes en trunk og en rutegruppe for hver lokal gateway, og ruteg ruppen tildeles derefter som PSTN-valget for placeringen. Cisco anbefaler kraftigt altid at vælge en rutegruppe som PSTN-valg, da denne tilgang giver dig mulighed for nemt at tilføje yderligere trunker i fremtiden, hvilket understøtter både skalerbarhed og redundans. Cisco anbefaler også at aktivere dual-identity og P-Charge-Info support på alle PSTN-trunker, da dette forenkler identifikationen af den fakturerbare part for udgående direkte eller omdirigerede opkald. Hvis din PSTN-udbyder bruger en anden header til fakturering, kan du kopiere oplysningerne fra P-Charge-Info-overskriften på den lokale gateway til den krævede faktureringsoverskrift.
For steder, der bruger Cloud Connect til eller Cisco Calling Plan som deres PSTN-mulighed, skal du blot vælge det respektive PSTN- valg for placeringen under opsætningen. Hvis placeringen bruger enten Cloud Connect til eller PSTN i det lokale miljø, skal du tilføje de telefonnumre, der blev bestilt i det foregående trin. Numre kan tilføjes som inaktive, hvis du ikke vil have dem inkluderet i op kaldsrouting med det samme; du kan aktivere disse numre senere, når de tildeles brugere eller funktioner.
Det er vigtigt altid at indstille hovednummeret for hver placering. Hovednummeret kan tildeles enten en bruger eller en funktion, såsom en automatisk ledsager. For at aktivere voicemail på stedet skal du sørge for at indstille telefon svarerens pilotnummer, også kendt som stemmeportalnummeret.
Yderligere indstillinger for opkaldssteder omfatter konfiguration af nø dopkaldsoplysninger såsom nødopkaldsnummeret, meddelelses muligheder og forbedrede nødopkaldsfunktioner. Du bør også gennemgå og justere optagelsesindstillinger, sprogindstillinger og enhedskon figurationer efter behov for hver placering. Hvis din organisation bruger forkortet internetopkald mellem websteder med virksomhedssignifikante numre, skal du huske at konfigurere en unik webstedskode for placeringen i de interne opkaldsindstillinger. Endelig, hvis ekstern opkald kræver et udgående opkaldsciffer, skal du sørge for at indstille dette i indstillingerne for ekstern opkald . Når der er konfigureret et ciffer for udgående opkald, anbefaler Cisco, at håndhævelse af udgående opkaldscifre aktiveres for at sikre konsistens.
Integration med opkaldskontrol i det lokale miljø
Hvis du vil integrere med opkaldskontrol i det lokale miljø, er det nødvendigt at konfigurere trunker, rutegrupper, virksomhedsopkaldsplaner og både placeringsindstillinger og globale indstillinger. Begynd med at konfigurere trunker og lokale gateways, der er beregnet til sammenkobling med det lokale opkaldskontrolsystem. Dette trin er kun påkrævet, hvis dedikerede trunker er nødvendige. Hvis eksisterende trunker og rutegrupper er tilstrækkelige til installationen, kan de genbruges til sammenkoblingen i det lokale miljø uden yderligere konfiguration.
Når trunkerne og rutegrupperne er oprettet, skal du fortsætte med at oprette virksomhedens opkaldsplaner og tildele den relevante rutegruppe som destination for hver opkaldsplan. Når integrationen involverer flere lokale opkaldsstyringssystemer, der er forbundet via forskellige trunker, kræves der flere opkaldsplaner. Det er vigtigt at sikre, at disse opkaldsplaner kun indeholder de mønstre, der er nødvendige for at dirig ere opkald til lokale destinationer.
Hvis installationen kræver understøttelse af ukendt udvidelsesrouting, skal denne funktion være aktiveret på placeringsniveau. Når routing af ukendt udvidelse er aktiveret, skal du desuden angive den maksimale ukendte forlængelseslængde i afsnittet Opkal dsdirigering mellem og lokaler i indstillingerne for opkaldstjenester i. Dette sikrer problemfri opkaldsrouting og korrekt håndtering af udvidelsesbaserede opkalds scenarier i dit integrerede miljø.
Overfør brugere i batcher
Når du overfører brugere fra til, kan du muligvis ikke flytte alle brugere på samme tid. Dette kan skyldes flere årsager, herunder men ikke begrænset til antallet af websteder eller brugere, hvor lang tid det tager at overføre et websted og/eller en gruppe af brugere på én gang, begrænset it- eller webstedsressource til at understøtte ændringsvinduet, varigheden af ændringsvinduet, ændringens kompleksitet osv.
Når du overfører brugere i faser, er det vigtigt at identificere, hvilke brugere der skal migrere sammen i samme batch. Det primære mål er at migrere brugere sammen, der har afhængigheder med hinanden for deres opkaldstjenester og funktioner. Du vil sikre, at alle deres opkaldsfunktioner (Eksempel - Opkaldskøer) er fuldt funktionsdygtige, som de var før overgangen til.
Selvom du implementerer opkaldssamarbejde mellem og med lokale gateways, kan du ikke opdele delte tjenester eller funktioner på tværs af denne forbindelse. Derfor skal du identificere afhængighederne mellem brugere ved at se på funktioner som:
-
Overvågning af andre brugere ved hjælp af BLF'er
-
I samme jagtpilot, opkaldskø osv
-
Delte linjer
-
Brug af opkaldsafhentning
-
Brug af de samme call-park-numre
-
Intercom
-
Eksekutiv/Administrator.
Et eksempel ville være en bruger, der er en del af en Hunt-gruppe, der overgår til. Denne bruger overgår til med Hunt Group og med alle andre medlemmer af Hunt Group. Derfor kan Hunt Group og dens medlemmer efter overgangen med succes besvare opkald på den nye platform.
Dette bliver mere udfordrende, når brugerne er forbundet til forskellige grupper af brugere for forskellige opkaldstjenester og funktioner. Dette kræver overgang af mere end en gruppe brugere og en opkaldstjeneste til på samme tid.
Brug outputtet fra værktøjet Migration Insights eller tredjepartsværktøjet, som du brugte i forberedelsesfasen, til at bestemme, hvilke brugere og funktioner der skal grupperes sammen. Dette output skulle have været brugt til at udvikle din overførselsplan og vil give dig indsigt i, hvordan du grupperer brugere og funktioner, der skal overgå sammen.
De vigtigste trin, når du overgår en batch af brugere, er:
-
Identificering af brugere, der skal migreres sammen
-
Bekræft, at alle brugere er inde
-
Bekræft, at alle TN'er for brugerne findes i
-
Bekræft korrekt telefonnummerformat i mappen
-
Sørg for, at licens- og indstillingsskabelonen for brugergrup perne er konfigureret korrekt
-
Verificering eller konfiguration af alle opkaldstjenester og -funktioner for gruppen af brugere (før eller under overgangen, alt efter hvad der er relevant)
-
Føj brugere til gruppen af opkaldsaktiverede brugere i virksomhedsmappen
-
Udnyt værktøjer - bruger- og funktionsmigreringsværktøjer og/eller tredjepartsværktøjer
-
Deaktiver/slet bruger/enhedens katalognummer og opkaldsfunktioner/tjenester til efter overgangen.
Efter overførsel af en gruppe brugere skal du teste en undergruppe af brugerne for at kontrollere, at alle deres opkaldsfunktioner og -tjenester fungerer korrekt. Hvis opkaldsfunktioner som opkaldskø, jagtgrupper osv. overføres med gruppen af brugere, skal du teste disse opkaldstjenester for korrekt funktionalitet.
Arbejdsområder
I refererer et arbejdsområde til en delt placering (f.eks. et mødelokale, mødelokale eller et hot desk), der kan tildeles enheder, udvidelser og brugere. I modsætning til traditionelle Unifed CM- telefoner er arbejdsområder:
-
Placeringscentreret: bundet til fysiske rum.
-
Enhedsfleksibel: kan have en eller flere enheder (skrivebordstelefoner, tavler osv.).
Når arbejdsområder er blevet identificeret som en del af overgangen til, kan de tilføjes under Enheder. Hvert arbejdsområde skal have en enhedstildeling, og hvis de allerede er iUnified CM, skal de nulstilles eller genklargøres til dem. funktioner som telefonsvarer, viderestilling af opkald og afhentning af opkald kan aktiveres eller deaktiveres, og politikker kan anvendes til videoopkald, opkaldsparkering og mobilitet efter behov. Test hvert arbejdsområde ved at foretage interne og eksterne opkald, teste video-, konference- og mobilitets funktioner. Endelig skal du fortælle brugerne om eventuelle relevante processer for arbejdsområdeenheder og bookinger.
Du kan finde flere oplysninger om arbejdsområder i under Arbejdsområder.
Tilvejebringelsesenheder
Telefoner, der i øjeblikket er registreret til, skal migreres til som en del af skyovergangen. For at gøre migreringen så enkel som muligt med minimal chance for fejl anbefaler Cisco, at du migrerer fysiske websteder eller afdelinger på samme tid. Du kan dog blive bedt om at migrere brugere i batcher på grund af funktionsafhængigheder. Se afsnittet Over før brugere i grupper for at få flere oplysninger.
Alle understøttede telefoner, som du har brug for at skifte fra, skal konfigureres som bruger eller arbejdsområde, og den fysiske telefon skal omkonfigureres for at registrere dig hos . Derudover har telefonerne i 7800- og 8800-serien brug for deres firmware opgraderet fra Enterprise- firmware til Multiplatform Phone (MPP) firmware. Denne proces omfatter indlæsning af overgangs firmware før indlæsning af den MPP-firmware, der kræves til registrering. Det kræver også den relevante migrationslicens. Cisco har forbedret denne proces i løbet af de sidste par år for at gøre det lettere for dig at opgradere dine Enterprise-firmwaretel efoner til MPP-firmware. Du kan finde flere oplysninger om trinene til at fuldføre firmwareopgraderingen i Konvertere IP-telefoner i Cisco 7800- og 8800-serien mellem Enterprise- og MP P- firmware.
Ud over de trin, der er beskrevet i denne artikel, har du et indbygget værktøj, Overfør din telefon til Webex Calling, som du kan bruge til at hjælpe med at migrere dine 7800- og 8800-telefoner fra Enterprise til MPP-firmware. Dette værktøj giver dig også mulighed for at tilføje telefonerne til og tildele dem til de relevante brugere eller arbejdsområder. Du kan finde flere oplysninger om værktøjsbrug under Overfør din telefon.
For telefoner i 9800-serien, der er registreret med ovenstående krav til firmwareoverførsel, gælder ikke. Disse telefoner kører PhoneOS, som understøttes af både og. For at overføre disse telefoner til skal du tilføje dem tilWebex Calling, tildele dem til en bruger eller et arbejdsområde og derefter fabriksindstille telefonerne. PhoneOS-opstartssekvens til registrering Figur nedenfor viser PhoneOS-opstartssekvensen, og hvordan telefonen vil registrere sig, når den er blevet tilføjet til, selvom telefonen stadig er klargjort og/eller DHCP-indstillinger (Eksempel - 150) er i brug.
understøtter fabriksindstilling af PhoneOS-enheder for at tillade Zero-Touch onboarding til. administratorer kan eksternt fabriksindstille 9800- og 8875-telefonerne via CUCM-administrationssi derne, hvilket eliminerer behovet for fysisk adgang til telefonerne, der skal indbygges telefonerne til. Denne funktion understøttes med enhedspakkerne fra 9. september 2025:
-
CUCM v15 - Unified Communications Manager version 15
-
CUCM v14 - Unified Communications Manager version 14.
For mere information om registreringsprocessen for 9800-serien, se Registrerings proces.
Ud over Cisco IP-telefonerne kan levering af andre enheder såsom analoge telefon adaptere (ATA), trådløse (Wifi, DECT) telefoner, videoenheder, stemmegateways og tredjepart senheder og telefoner være påkrævet. Mange af disse enheder har ikke en firmwareopgraderingssti som IP-telefonerne til at overføre dem fra virksomhedsfirmware til cloud- firmware. Derfor klargør du hver af disse enheder i Control Hub. Nogle af disse kan ikke overføres til, og den tilsvarende model skal erstatte den (f.eks. ATA 191/192) og andre vil kræve manuel rekonfiguration og/eller softwareændringer.
- Stemmegateways — Hvis du vil migrere din lokale gateway, skal du se Over føre lokal gateway.
-
Analog telefonadapter (ATA) - For at komme i gang med din Cisco ATA 191 og 192, se Cisco ATA.
-
Trådløs WiFi-telefon - Se Integrere trådløs Webex-telefon for at integrere trådløs telefon 840 og 860.
-
Trådløse DECT-telefoner - Se Cisco IP DECT 6800-serien for at komme i gang med din nye Cisco IP DECT 6800-serie.
Hvis du vil oprette og administrere digitalt DECT-netværk i Control Hub, skal du se Administrer DEC T-netværk
Du kan finde flere oplysninger om Cisco IP DECT 6800 i Installationsvejledning
-
Tred je partsenheder og -telefoner - Arbejd med tredje part sleverandører om enheds-/telefonkrav og processen til at migrere eller erstatte dem til support.
Konfigurer funktioner
Alle opkaldsfunktioner, der kræves, skal klarlægges før eller under overgangen. Som beskrevet i afsnittet Over før brugere i batcher skal opkaldsfunktionerne konfigureres og overføres, når de brugere, der bruger dem, overføres.
Du kan finde flere oplysninger om, hvordan du konfigurerer hver af funktionerne, i de tilsvarende artikler om konfigurationshjælp.
-
Opkaldspark - Se Opkaldspark for at administrere op kald sparkering
-
Afhentning af opkald — Se Afhentning af opkald, hvis du vil konfigurere gruppen for afhentning af opkald
-
Opkaldskøer - Hvis du vil konfigurere opkaldskø, skal du se Op kald skø
-
Jagtgrupper — Se Administrer jagtgruppe for at administrere jagt grupper
-
Driftstilstande - Hvis du vil foretage opkaldsruting baseret på driftstilstande, skal du se Rute opkald baseret på driftstilstande
-
Personsøgningsgrupper — Hvis du vil konfigurere en personsøgningsgruppe, skal du se Konfigurere en personsøgningsgruppe
-
Optagelser - Hvis du vil administrere opkaldsoptagelse for, skal du se Administrer optagelser
-
Enkeltnummerrækkevidde - Hvis du vil konfigurere rækkevidde af et enkelt nummer (kontor hvor som helst), skal du se Konfigurere enkeltnummer
Accepttest
Accepttest sikrer, at det migrerede miljø opfylder funktionskravene, fungerer som forventet og leverer en problemfri brugeroplevelse på tværs af alle kommunikationsarbejdsgange. Denne validerings proces er mangefacetteret og dækker alt fra brugerklargøring og nummertildelinger til den operationelle ydeevne af avancerede opkaldsfunktioner.
Dette afsnit indeholder eksempler og fremhæver nøgleaspekter, der skal overvej es under accepttest; det er dog ikke beregnet til at fungere som en udtømmende eller omfattende tjekliste.
Brugerklargøring og nummertildeling
Et grundlæggende aspekt af accepttest involverer at verificere, at alle brugere er klargjort nøjagtigt og fuldstændigt indeni. Dette kræver en grundig sammenligning mellem source () -mappen og den nyoprettede brugerbase for at sikre, at alle brugerkonti sammen med tilknyttede attributter såsom ud videlsesnumre og DID-tildelinger (Direct Inward Opal) er blevet overført korrekt. Fuldstændighed af klargøring er afgørende ikke kun for funktionsdygtigheden på den første dag, men også for løbende administration og support.
Validering af nummertildeling omfatter bekræftelse af, at hver bruger er tildelt den korrekte udvidelse og det eksterne nummer, og at disse numre dirigeres korrekt i både interne (på nettet) og eksterne (PSTN) opkaldsstrømme. Det er vigtigt at kontrollere eventuelle overlapninger, manglende tildelinger eller fejlkonfigurationer, der kan føre til opkaldsroutingsfejl eller serviceafbrydelser.
PSTN-opkaldsstrømme og præsentation af opkalds-id
En robust accepttestprocedure skal omfatte ende-til-ende- validering af PSTN-opkaldsstrømme. Dette omfatter både indgående og udgående opkaldsscenarier . For indgående PSTN-opkald skal testteamet bekræfte, at opkald leveres til de tilsigtede slutpunkter, uanset om det er individuelle brugere, opkaldskøer, jagtgrupper eller automatiske telefonsvarere. Udgående PSTN-opkald skal foretages med succes, med særlig opmærksomhed på korrekt levering og præsentation af opkalds-ID-oplysninger. Dette indebærer at sikre, at det korrekte opkaldsnavn og nummer vises for eksterne modtagere i overensstemmelse med organisationspolitikker og lovkrav.
Test bør også behandle failover-scenarier, såsom håndtering af utilgæng elige slutpunkter eller netværksforstyrrelser. Dette hjælper med at bekræfte, at reservemekanismer og alternativ routing fungerer korrekt, hvilket opretholder servicekontinuitet og pålidelighed.
Opkaldsstrømme på nettet
Interne eller on-net opkaldsstrømme udgør rygraden i virksomhedskom munikation. Accepttest i dette område bekræfter, at opkald mellem brugere i organisationen dirigeres korrekt, med funktioner som opkaldsoverførsel, hold, videresendelse og konferencer, der fungerer efter hensig ten. Integriteten af opkaldsplaner, forbindelse mellem udvidelse til udvidelse og understøttelse af organisatoriske op kaldspolitikker skal alle bekræftes.
Håndtering af brugeropkald og funktionsvalidering
Et vigtigt aspekt af accepttest involverer validering af, hvordan brugerne håndterer opkald ved hjælp af de og understøttede bordtelefoner. Denne proces fokuserer på at bekræfte, at daglige opkal dsarbejdsgange er intuitive og pålidelige, og at brugerne har problemfri adgang til de kerne funktioner, der er nødvendige for deres roller. Test skal vurdere, hvor let brugerne kan foretage og modtage opkald, administrere hold- og genoptagelsesfunktioner og udføre både blinde og rådgivende overførsler. Det er også vigtigt at kontrollere, at viderestilling af opkald, konferencer og andre avancerede funktioner, såsom parkering og hentning af opkald eller aktivering af forstyrr ikke, er let tilgængelige og fungerer problemfrit.
Oplevelsen bør evalueres for klarhed og lydhørhed under hensyntagen til, hvordan brugerne interagerer med opkaldshistorik, voicemail og integrerede mapper. Der bør lægges yderligere vægt på muligheden for at flytte aktive opkald mellem enheder og til at bruge opkaldskontroller effektivt inden for applikationen eller på fysiske telefoner. Det ultimative mål er at sikre, at slutbrugeroplevelsen er konsekvent, effektiv og fuldt ud understøtter organisationens kommunikationsbehov efter migreringen.
Opkaldskøer: Agent- og vejledererfaring
Opkaldskøer bruges ofte til håndtering af indgående opkaldsscenarier med høj volumen. Accepttest fokuserer her på flere dimensioner. Først skal det verificeres, at opkald distribueres til agenter i henhold til den konfigurerede kølogik, såsom round robin, længste tomgang eller samtidig ring. Præsentationen af opkald i kø på agentdesktops skal undersøges for klarhed og brugervenlighed, hvilket sikrer, at ag enterne effektivt kan acceptere, holde og overføre opkald.
For vejledere bør skrivebordsoplevelsen evalueres for funktioner som realtidsovervågning, opkaldsbarging og analyse eller indsigt i køens ydeevne. Dette omfatter, men er ikke begrænset til, validering af dashboards og rapporteringsværktøjer, der giver handlingsbare data om opkalds distribution, agentaktivitet og kømålinger.
Jagtgrupper: Opkaldsfordeling
Jagtgrupper er en nøglemekanisme til distribution af opkald til foruddefinerede sæt brugere. Accepttest skal bekræfte, at opkald dirigeres til gruppemedlemmer baseret på den konfigurerede jagtalgoritme, og at overløb, videresendelse og no-svar scenarier håndteres i henhold til design. Det er afgørende for driftskonsistens og brugertilfredshed at sikre, at gruppemedlemskab og opkaldsroutingadfærd matcher dem, der tidligere er etableret i.
Automatiske svarbeskeder: Meddelelser og menuhandlinger
Autorespondenter repræsenterer frontlinjen for automatiseret opkaldshåndtering. Test skal dække afspilning af meddelelser, nøjagtigheden af optagede hilsener og korrekt betjening af menutræer. Menu valg skal pålideligt dirigere opkaldere til de relevante afdelinger, enkeltpersoner eller eksterne numre. Test bør også omfatte ugyldige scenarier eller timeout-scenarier for at bekræfte, at opkaldere modtager klar vejledning eller omdirigeres efter hensigten.
Voicemail-betjening
Endelig er voicemail-funktionalitet afgørende for brugeroplevelsen. Accepttests skal kontrollere, at voicemail-bokse er korrekt tildelt og tilgængelige, både inden for organisationen og eksternt. Evnen til at optage, hente og administrere meddelelser skal bekræftes sammen med meddelelseslevering.
Optimer
PSTN-overførsel til Cloud Connect til
Når alle slutpunkter og brugere er migreret til cloud-opkald, Unified CM er det eneste formål at fungere som en transit mellem PSTN-gateways og via Local Gateway. Fjernelse af PSTN-gateways og Local Gateway fra billedet ved at bruge Cloud Connect som PSTN-adgang for alle Webex Calling brugere har flere fordele, herunder omkost ningsreduktion og forbedret pålidelighed. Følg disse trin for at overføre PSTN-adgang i det lokale miljø til Cloud Connect for :
-
Cloud Connect til valg af partner.
Se listen over Cloud Connect for partnere, og vælg blandt de tilgængelige partnere, der er tilgængelige for din organisations placering.
-
Cloud Connect til validering.
Før du skifter PSTN-adgang for lokationer til Cloud Connect, skal forbindelsen til PSTN via den valgte Cloud Connect-partner verificeres og valideres. Til dette formål skal der etableres en testplacering med nogle testbrugere, der er klargjort på den pågældende testplacering. PSTN-adgang til denne test placering indstilles derefter til Cloud Connect-partneren, før PSTN-forbindelsen valideres ved hjælp af testtelefonerne. Efter vellykket validering kan testplaceringen afklar es.
-
Nummerportering.
For at forberede overgangen til Cloud Connect skal der placeres en portordre for alle numre, der aktuelt er tildelt PSTN-trunken, der afsluttes. Alle numre skal overføres til Cloud Connect-partneren. For at opretholde interlokationernes tilgængelighed skal alle numre på alle placeringer portes på samme tid.
-
Skift til Cloud Connect-partner.
På datoen for overgangen skal PSTN-adgang for alle placeringer indstilles til Cloud Connected PSTN-udbyderen, og indgående og udgående forbindelse skal verificeres.
Som diskuteret i PSTN-afsnittet i designkapitlet kan kunder også vælge at flytte deres PSTN-adgang til Cloud Connect til i starten af overgangen ved hjælp af PSTN-trunking til hybrid-implementeringer. Du kan finde flere oplysninger under PSTN-trunking til hybridinstallationer. Webex Calling I dette tilfælde er PSTN-adgang under overgangen via lokal gateway, og efter at alle brugere er flyttet til, er der ikke noget yderligere PSTN-relateret migrationstrin bortset fra nedlæggelse og de lokale gateways.
Optimer infrastrukturen i det lokale miljø
Når alle brugere er blevet overført til, og alle slutpunkter er blevet overført til cloud-registrering (eller er blevet taget ud af drift), skal du opdatere passende infrastruktur i det lokale miljø, nu hvor cloud-opkald er i brug. Opdateringer af infrastrukturen omfatter:
-
Fjern opkaldsstyring og meddelelses DNS SRV poster i det lokale miljø fra DNS-serveren (e) i det lokale miljø, herunder cisco_uds. _tcp. <domain>, cup_login. _tcp. <domain>. Disse SRV-poster er ikke længere nødvendige for opdagelse af klienttjenester.
-
Fjern kantrelaterede DNS SRV poster fra det offentlige DNS-system inklusive collab_edge. _tls. <domain>. Disse SRV-poster er ikke længere nødvendige for klientserviceopdagelse af kant tjenester for samarbejde.
-
Opdater alle relevante DHCP-områder for at fjerne option 66 og mulighed 150 TFTP/boot serveradresser. Disse anvendelsesområder er ikke længere nødvendige for opdagelse og download af konfiguration af slutpunktopkaldskontrol.
-
Opdater/fjern passende opkaldskammerater i Lokal gateway/kube, der dirigerer opkald til og fra. Unified CM Disse opkaldsmodparter er ikke længere nødvendige for opkaldsrouting i det lokale miljø.
-
Slet eller fjern alle virtuelle maskiner og/eller servere i klyngeknudepunkter. Genanvend beregningsressourcer og hardware efter behov. Disse ressourcer er ikke længere nødvendige til opkaldskontrol og kanttjenester.
-
Slet eller fjern alle virtuelle klyngeknudemaskiner og/eller servere. Genanvend beregningsressourcer og hardware efter behov. Disse ressourcer er ikke længere nødvendige for telefonsvarer og samlede meddel elsestjenester.
-
Oprydning: Efter migrering af PSTN-adgang til Cloud Connected PSTN kan PSTN-trunker, PSTN-gateways og Local Gateway deaktiveres.
-
For enhver eksisterende E911-løsning i det lokale miljø skal du slette alle placeringer eller numre, der er migreret til, og når den fulde overgang er fuldført, fjerne virtuelle applikationsmaskiner eller -servere. Genanvend beregningsressourcer og hardware efter behov. Disse ressourcer er ikke længere nødvendige til nødopkald og lokaliseringstjenester.
-
DN'er, der tilhører migrerede brugere, skal placeres i en skjult partition for at undgå fejl i opkaldsrouting og for at sikre, at alle CSS'er har prioriteret adgang til skystien for de samme DN'er.
-
Opdater den fysiske afsendelsesplacering og netværkselementet i horisontmobilitet, når der sker ændringer. Almindelige aktiviteter, der kræver opdateringer, er:
-
Udskiftning af netværksafbryder
-
Udskiftning af trådløst adgangspunkt
-
Ændringer i DHCP-omfang
-
Fysiske ændringer inde i bygningen (hvis de løses til kubikal/kontor)
-
Fysisk udvidelse eller sammentrækning af kontorlokaler inde i en bygning.
-
Brug analyser og fejlfinding
giver omfattende analyse- og fejlfindingsfunktioner, der hjælper dig med at visualisere og spore din implementering. Disse dækker mediekvalitet, detaljeret opkaldshistorik, opkaldskø, jagt gruppe og automatisk ledsager analyse. Et eksempel på mediekvalitetsanalyse er vist i figur mediekvalitetsanalyse.
Under fejlfinding kan hvert opkald, der foretages ved hjælp af, ses med detaljerede oplysninger om vigtige mediekvalitet og signalrelaterede problemer for at hjælpe med at identificere medieproblemer såvel som mislykkede opkald, som vist i fejlfinding af medi ekvalitet i figuren.
Fejlfinding kan også integreres med andre Cisco-produkter som ThousandEyes og Meraki- switche for at give en endnu rigere integreret oplevelse i Control Hub. Du kan finde flere oplysninger om brug af Webex Callinganalyse og fejlfinding under Fej lfinding af Webex Calling opkald i Control Hub.
Introduktion
Før du begynder
Denne vejledning er beregnet til teams eller enkeltpersoner med erfaring i konfiguration og administration af Cisco Unified Communications Manager (Unified CM) og Cisco-slutpunkter, herunder IP-bordtelefoner, videoenheder og Jabber-softwareklienter. I hele dette dokument er der links til produkt- og supportdokumentation, der kan hjælpe.
Dette dokument fokuserer kun på overgange fra Unified CM til Webex Calling multi-tenant. Udtrykket Webex Calling i dette dokument refererer altid til Webex Calling multi-tenant.
Før man påbegynder migreringen fra Unified CM til Webex Calling, er det bydende nødvendigt at have en omfattende forståelse af Webex Calling-løsningen og dens respektive komponenter. En vellykket migrering kræver kendskab til Webex Calling-arkitekturen, servicemodeller, implementeringsmuligheder og tilhørende funktioner for korrekt at kortlægge eksisterende Unified CM-arbejdsbelastninger og designe en effektiv overgangsplan.
En grundig forståelse af følgende Webex Calling-komponenter er afgørende for at kunne udarbejde en effektiv overgangsstrategi og opnå operationel beredskab.
-
Control Hub
-
Klargøring af katalog og bruger
-
Webex Calling-platform
-
Understøttede opkaldsslutpunkter
-
PSTN-forbindelsesmuligheder
-
Webex Calling opkaldsplan og nummeradministration
-
Sikkerheds- og overholdelsesfunktioner.
For mere information, se Cisco Preferred Architecture for Webex Calling.
Denne vejledning vil fremhæve værktøjer og processer, der skal bruges gennem hele overgangscyklussen. En overgang fra lokale opkald, Unified CM, til en ny cloud-opkaldsplatform, Webex Calling, kan dog være en betydelig indsats med potentielle forretningsmæssige, tekniske og komplekse udfordringer. For at hjælpe med at overvinde disse udfordringer har Cisco et par forskellige muligheder tilgængelige for at hjælpe dig på din rejse. Det er vigtigt at gennemgå oplysningerne på Enterprise cloud calling - Calling migration og forstå hver mulighed, og hvordan hver enkelt muligvis kan hjælpe dig med din egen migrering.
-
Webex-migreringsværktøjer: Selvbetjeningsværktøjer, der er indbygget i Control Hub, for at strømline din overgang til Webex Calling
-
Certificerede migrationsudbydere: Cisco-validerede software- og værktøjsudbydere, der har udviklet migreringsløsninger til at hjælpe Webex-partnere og -kunder med komplekse og store migreringer. Disse løsninger kan hjælpe med at forenkle, administrere og fremskynde overgangen til Webex Calling.
-
Webex opsætningshjælp: en Cisco-ledet migreringstjeneste, der guider kunder og partnere gennem Webex Calling-implementeringen og -konfigurationen, hvilket er nødvendigt for at migrere Unified CM-brugere og -tjenester til Webex Calling.
Overblik
Med væksten af cloud-leverede samarbejdstjenester ønsker flere kunder at flytte deres eksisterende samarbejdsbelastninger til skyen i betragtning af løfterne om reducerede samlede ejeromkostninger, forenklet administration, kontinuerlig levering af funktioner, øget skalering og overlegen pålidelighed, der er forbundet med cloud-baserede tjenester. Når kunder ønsker at skifte fra lokale til cloud-baserede samarbejdstjenester, er det vigtigt for dem at forstå, hvad overgangen indebærer, og de trin, der kræves for at gennemføre overgangen.
Formålet med dette dokument er at give implementeringsvejledning til kunder, der specifikt ønsker at overgå fra lokal Unified CM til Webex Calling i skyen. Denne implementeringsvejledning forudsætter, at læseren har en grundlæggende forståelse af opkaldsovergangen mellem Unified CM og Webex Calling, herunder hvilke ændringer der sker ved denne overgang, og hvilke forskelle der er, når opkaldsarbejdsbyrden flyttes fra det lokale miljø til skyen. Før du fortsætter, skal du sørge for at have gennemgået og er bekendt med de oplysninger, der er tilgængelige på Transitionskort. Dette overgangskort indeholder oplysninger om ændringerne og forskellene i denne overgang.
Som vist i figur Arkitektur for lokalt samarbejde: Opkaldsstyring og fjernadgang, en typisk lokal implementering inkluderer forskellige samarbejdsinfrastrukturkomponenter på netværket, en opkaldsstyringsplatform, en edge-platform, hardware- og software-slutpunkter og i nogle tilfælde endda konference- og planlægningsplatforme. I Cisco-arkitekturen ville dette omfatte Unified CM til opkaldsstyring, Expressway til fjernadgang og business-to-business (B2B) edge-tjenester, Cisco Meeting Server / Cisco Meeting Management til lokale konferencer, Unity Connection til telefonsvarere og brugervendt hardware (Cisco IP-telefoner, Cisco Desk- og Room-videosystemer) og software (Cisco Jabber) IP-baserede slutpunkter. Disse komponenter kan variere en smule i visse miljøer, men dette er udgangspunktet for den overgang, der er beskrevet i resten af dette dokument.
Arkitekturen vist i figur Arkitektur for lokalt samarbejde: Opkaldsstyring og fjernadgang er baseret på den foretrukne arkitektur (PA) til Cisco Collaboration Enterprise On-Premises-implementeringer. For mere information om Enterprise On-premise, se Ciscos foretrukne arkitekturer til samarbejde.
Før: Tabellen Komponenter til infrastruktur for lokale opkald viser nøgleelementerne i den lokale arkitektur før overgangen til Webex Calling i skyen.
| Produkt | Beskrivelse |
|---|---|
| Unified CM | Lokal opkaldsstyring, der leverer enhedsregistrering og opkaldsroutingtjenester |
| Cisco Expressway-C/E | Edge-infrastruktur, der leverer mobil- og fjernadgang (MRA) og business-to-business (B2B)-funktionalitet, der gør det muligt for eksterne slutpunkter at oprette sikker forbindelse fra eksterne organisationer. Expressway implementeres parvis for at give firewall-gennemgang til eksterne slutpunkter. |
| Cisco Meeting Server (CMS), Cisco Meeting Management (CMM) og Cisco Telepresence Management Suite (TMS) | Lokal infrastruktur til tale-, video- og webkonferencer, der leverer multipunktmøder, mødestyring og planlægningsfunktioner. [Optional] |
| Cisco Unity Connection | Lokal platform til talebeskeder, der leverer talebeskeder og samlede beskedfunktioner. [Optional] |
| Cisco Desk, Cisco Room, Cisco Board, Cisco IP-telefoner og Cisco Jabber | IP-baserede enheder registreret i Unified CM og med mulighed for tale- og videoopkald |
Som illustreret i figur Overgangsbeslutning: Lokale opkald til Webex Calling, kunder, der har lokal opkaldskontrol med Unified CM og skrivebords- og video-IP-slutpunkter, har mulighed for at overføre arkitekturen til en Webex Calling Cloud-arkitektur.
Beslutningen skal træffes baseret på kundens funktionalitetskrav. Kunder, der har følgende krav, bør overveje dette nøje, inden de træffer denne beslutning, og kan i sidste ende beslutte at beholde opkaldsstyringen lokalt:
- Telefonmodeller understøttes ikke af Webex Calling
- Komplekse eller talrige integrationer med andre lokale systemer eller løsninger, især hvor det er vanskeligt at replikere disse integrationer med Webex Calling, eller hvor der ikke findes tilsvarende alternative løsninger.
- Kompleks opkaldsplan, meget detaljerede serviceklasser eller begge dele
- Begrænset, restriktiv eller upålidelig internetadgang
- Strenge politikker for databeskyttelse og ejerskab
- Overholdelseskrav for medieoptagelse og -lagring på stedet eller i landet
- Tredjepartsintegrationer uden en brugbar alternativ Webex Calling-integration
- Kontaktcenterintegrationer, hvor kontaktcenterintegrationen ikke flytter til skyen endnu.
Dette dokument fokuserer på kunder med Unified CM-opkaldskontrolinstallationer, der ønsker at forstå de generelle trin, overvejelser og krav til aktivering af Webex Calling-installation, som beskrevet i næste afsnit.
Kernekomponenter
Målarkitekturen for denne migrering indeholder flere nye komponenter. Dette inkluderer Webex Calling-tjenesten til cloudbaserede opkald, Webex-appen, Cisco Directory Connector til identitetsintegration og Local Gateway (LGW) til PSTN-adgang, samt integration af lokale opkald i cloud-miljøet. Cisco-opkaldsabonnementer eller Cloud Connected PSTN (CCP), der faciliteres af en Cloud Connect til Webex Calling-partner, er yderligere muligheder for PSTN-adgang.
Som vist i figur Efter: Webex Calling Architecture, de nye komponenter (Webex Calling, Directory Connector, Local Gateway og Survivability Gateway) føjes til den eksisterende lokale implementering.
Efter: Tabellen "Components for cloud-opkaldsinfrastruktur" viser de nye elementer i arkitekturen efter overgangen til Webex.
| Produkt | Beskrivelse |
|---|---|
| Webex Calling | Cloudbaseret opkaldstjeneste leveret fra Webex-platformen og med slutpunktsregistrering og opkaldsrouting |
| Cisco Directory Connector | Windows-applikation, der kører på en Windows-domænemaskine, og som leverer identitetssynkronisering mellem virksomhedens lokale Active Directory og Webex-organisationens identitetslager. For kunder, der flytter fra lokal Active Directory til Entra ID, bruger identitetsintegrationen med Webex i stedet for Cisco Directory Connector Entra ID Wizard-appen. |
| Lokal gateway | En lokal gateway fungerer som en bro mellem en kundes lokale Unified Communications-netværk og Webex Calling-skyen. Den kan implementeres lokalt eller hostes af en partner, og leverer PSTN-adgang til cloud-registrerede slutpunkter samt opkaldsintegration mellem Unified CM-registrerede og cloud-registrerede slutpunkter. Cisco IOS-XE Integrated Services Router (ISR 1100- og 4000-serien), Cisco Catalyst 8200/8300 Serien, Cisco Catalyst 8000V Edge-software og forskellige certificerede tredjeparts Session Border Controllers (SBC'er) kan bruges som en LGW til en faseopdelt migreringsmetode. |
| Overlevelsesgrad for gateway | Survivability Gateway (SGW) er en lokal netværks-iOS-XE-baseret gateway, der leverer reserveopkaldstjenester til Webex Calling-slutpunkter på stedet under netværksafbrydelser. |
| Cisco-opkaldsabonnement, Cloud Connect til Webex-opkald | Cisco Calling Plan og Cloud Connect til Webex Calling er cloudbaserede muligheder for PSTN-adgang til Webex Calling-slutpunkter. PSTN-adgang muliggøres af en cloud-PSTN-udbyder og kræver intet lokalt udstyr. |
| Webex-app | Klientapplikation, der kører på desktop-OS (Windows, Mac) eller mobil-OS (Android, iOS) og er registreret direkte på Webex Calling-platformen til opkaldsfunktionalitet. |
Oversigt over PPDIO-processen
PPDIO - processen står for Forbered, planlæg, design, implementer og optimer. Det er en struktureret Cisco-metode, der guider projekter fra den indledende vurdering til løbende forbedringer, hvilket sikrer effektive og succesfulde implementeringer eller migreringer.
Generel beskrivelse af PPDIO
-
Forberede: Vurder det nuværende miljø, indhent krav og samordn interessenter for at etablere et solidt fundament.
-
Plan: Udvikle detaljerede projektplaner, herunder tidslinjer, ressourcer og strategier for risikoreduktion.
-
Design: Udarbejd målløsningen, der er skræddersyet til forretningsmæssige og tekniske behov.
-
Implementér: Udfør implementeringen eller migreringen i henhold til designet, og validér funktionalitet og ydeevne.
-
Optimer: Løbende forbedring af løsningen efter implementering ved at overvåge ydeevne, forfine konfigurationer og udnytte automatiserings- og integrationsværktøjer.
Brug af PPDIO til migreringsprojekter fra Unified CM til Webex Calling
Ved overgang fra Unified CM til Webex Calling giver PPDIO-processen en klar køreplan for at sikre en problemfri og effektiv overgang:
Forbered
-
Vurder det eksisterende Unified CM-miljø og migreringsparathed
-
Indsaml detaljerede data om brugere, enheder, netværk og afhængigheder
-
Indsaml lokationsoplysninger, herunder adresse til nødberedskab, antal brugere, internetadgang og PSTN-adgang
-
Identificer risici og definer projektets omfang for at bringe alle interessenter i overensstemmelse med hinanden.
Planlæg
-
Opret en omfattende migreringsplan med batchplaner, ressourcetildelinger og tidslinjer
-
Definer opgaver såsom opgraderinger af enhedsfirmware, licensprovisionering og brugerintroduktion
-
Koordinér migreringsvinduer med Cisco og partnere for at minimere afbrydelser.
Design
-
Knyt aktuelle Unified CM-konfigurationer, opkaldsplaner og brugerprofiler til Webex Calling-ækvivalenter
-
Design Webex Calling-miljøet, inklusive PSTN-strategi (midlertidig og endelig), placeringer, brugerroller og integrationspunkter som Local Gateway (CUBE) og katalogsynkronisering
-
Planlæg for sameksistensscenarier, hvor Unified CM og Webex Calling fungerer samtidigt under migreringen.
Implementer
-
Brug Control Hub-migreringsværktøjer sammen med tredjepartsværktøjer til at udføre ændringer af enhedsfirmwaretilstand, funktionskonfiguration og brugermigreringer.
-
Anvend masseoperationer og klargøring ved hjælp af Webex API'er for at strømline storstilede migreringer og konfigurationer
-
Udfør licensprovisionering, enhedsregistrering og konfigurationsopdateringer
-
Valider migreringens succes gennem test og operationel verifikation.
Optimer
-
Løbende overvågning af Webex Callings ydeevne og brugeroplevelse
-
Forfin konfigurationer og arbejdsgange baseret på driftsdata og feedback
-
Udnyt automatiserings- og integrationsfunktioner for at forbedre effektivitet og skalerbarhed
-
Afmonter ældre Unified CM-komponenter efter behov og yd løbende support til daglig drift.
Denne forbedrede PPDIO-tilgang sikrer en kontrolleret, transparent og effektiv migrering fra Unified CM til Webex Calling, der udnytter Ciscos værktøjer, API'er og partnerøkosystem til at opretholde forretningskontinuitet og forbedre samarbejdsmuligheder.
PPDIO-feedbackløkker
Oversigten på højt niveau, der er vist i figur Iterationer under udførelse af PPDIO, illustrerer en enkelt feedback-loop fra optimerings- fasen tilbage til forberedelses- fasen. Dette betyder, at der efter den første implementering er en løbende mulighed for løbende forbedringer. Hver optimeringscyklus kan identificere nye krav eller områder til forbedring, som kan adresseres gennem efterfølgende projekter eller initiativer. Disse individuelle projekter følger til gengæld hver især den etablerede PPDIO-livscyklus (Forbered, Planlæg, Design, Implementer, Optimer). Denne iterative tilgang sikrer, at systemet forbliver i overensstemmelse med udviklende forretningsmål og teknologiske fremskridt, hvilket fremmer en kultur af løbende forbedring og tilpasningsevne.
Under udførelsen af PPDIO-processen er det almindeligt, at fund i de senere faser nødvendiggør genvurdering og potentielt revision af beslutninger truffet i tidligere stadier. For eksempel kan problemer, der opstår i implementeringsfasen, såsom identifikation af designmæssige uklarheder eller manglende detaljer, afsløre, at visse aspekter ikke blev fuldt ud behandlet i designfasen. I sådanne tilfælde bliver det nødvendigt at gå tilbage til den relevante tidligere fase for at løse disse problemer, før man fortsætter. Denne iterative feedbackmekanisme, som illustreret i figur Unified CM assisted PPDIO process, sikrer, at løsningen valideres og forfines grundigt, hvilket i sidste ende bidrager til en mere robust og effektiv implementering.
Når man foretager en overgang fra Unified CM til Webex Calling, kan hver fase af PPDIO-processen drage betydelig fordel af oplysninger indsamlet fra det eksisterende Unified CM-miljø. For eksempel kan omfattende opgørelser over brugere, telefonnumre, opkaldsfunktioner og opkaldsplankomponenter udtrækkes fra den aktuelle Unified CM-konfiguration. Disse data supplerer information leveret direkte af interessenter og hjælper med at strømline planlægnings- og designaktiviteter. Udnyttelse af passende værktøjer til at automatisere dataudtrækning og -analyse forbedrer ikke kun nøjagtigheden, men fremskynder også den samlede proces. Ved at udnytte indsigt fra den eksisterende implementering kan overgangen til Webex Calling udføres mere effektivt end en traditionel, ny implementering, samtidig med at den strukturerede PPDIO-metode overholdes. Denne proces er illustreret i figur Unified CM assisteret PPDIO-proces.
Migrationstilgang
Når du planlægger din overgang fra lokal Unified CM til Webex Calling, skal du bestemme, hvordan du vil gribe denne rejse an. Først skal du beslutte, om migreringen skal være en flash-cut (alt på én gang) eller en faseopdelt tilgang (migrer grupper af users/devices over en længere periode).
En flash-cut migrering flytter alle dine brugere og enheder hurtigst. Med denne metode flytter du alle brugere og enheder fra den lokale Unified CM til Webex Calling på samme tid. I bund og grund er det ét enkelt migreringsvindue for alle brugere og enheder. Når denne migrering er fuldført, vil alle dine brugere og enheder være på Webex Calling-platformen, og al din Unified CM-infrastruktur kan tages ud af drift. Mange organisationer kan dog ikke bruge denne tilgang på grund af omfanget og størrelsen af deres opkaldsimplementering.
Den anden tilgang er en faset migrering. De fleste organisationer vil bruge denne tilgang, da den giver bedre kontrol, administration og skalering med migreringen. Den er også bedre egnet til større UC-implementeringer and/or implementeringer på tværs af flere regioner. Derfor fokuserer dette dokument på den faseopdelte tilgang med to trin i overgangen.
Som vist i figur nedenfor: Fasevis overgang til opkald: Hybrid og cloud, den første overgangsfase (fase 1) resulterer i en sameksistensimplementering med dobbelte opkaldsmiljøer. I denne fase overgår nogle brugere, enheder og soft-klienter til Webex Calling, mens andre stadig er på den lokale Unified CM-opkaldskontrol. Den sidste overgangsfase (fase 2) resulterer i et rent cloud-opkaldsmiljø, hvor alle brugere, enheder og soft-klienter er blevet fuldt overført til Webex Calling-platformen.
Hvor lang tid det tager for en organisation at overgå fuldstændigt til cloud-opkald, vil variere afhængigt af den nuværende implementering. I nogle tilfælde kan en organisation foretage den indledende overgang og forblive i sameksistensfasen med dobbelt opkaldskontrol (fase 1) i en længere periode (måneder eller endda år), mens en organisation i andre tilfælde kan overgå fuldt ud til Webex Calling (fase 2) på meget kort tid (uger eller måneder). Dette dokument har til formål at dække begge faser (Fase 1 - sameksistens og Fase 2 - fuldt omstillet).
Det er muligt, at nogle organisationer vil opretholde en sameksistens-dual opkaldskontrol-implementering på ubestemt tid uden planer om nogensinde fuldt ud at overgå til cloud-opkald.
Den anden overvejelse er, hvordan du vil overføre brugere, enheder og softklienter fra den lokale opkaldskontrol til den skybaserede opkaldskontrol. Den anbefalede tilgang er en 3-faset overgang. Figuren Anbefalet 3-faset overgang nedenfor opdeler denne tilgang i de 3 faser.
Før migration: Denne fase fokuserer på at gøre både Webex- og Unified CM-miljøerne klar til migreringen. Dette handler ikke om specifik planlægning eller konfiguration af opkald, men fokuserer på at fuldføre aktiviteter, der kan udføres nu og før et Webex Calling-migreringsprojekt starter. Målet er at bygge fundamentet for, at de to miljøer kan forberede sig på migrationen.
Forberedelse af migration: I denne fase begynder arbejdet med at forberede migreringen til Webex Calling. Her skal forretningsmæssige og tekniske krav gennemgås og opdateres. Foretag ikke bare en opgradering af det, der i øjeblikket er implementeret med Unified CM, men omdefiner i stedet de forretningsmæssige og tekniske krav, som din virksomhed har brug for i dag og i fremtiden, ved at udnytte kraften i Webex Calling. Derudover er dette fasen, hvor du vil færdiggøre dit design, konfigurationsplanlægning og migrering. planning/schedule.
Migrering (udrulning og nedlukning): Denne fase er der, hvor den faktiske migrering af brugere, enheder, telefonnumre og softklienter finder sted. Som beskrevet ovenfor kan denne fase gennemføres for alle på én gang (flash-cut) eller over flere ændringsvinduer (phased-cut). Planer for slutbrugernes implementering, træning og kommunikation er afgørende, så dine brugere er opmærksomme på ændringerne, hvordan de bruger den nye opkaldsplatform, og ved, hvornår ændringen vil ske. Det sidste trin er at afvikle al den lokale UC-infrastruktur, der ikke længere bruges.
Før-migreringsfasen indeholder aktiviteter (obligatoriske, anbefalede og valgfrie), som du kan begynde at arbejde på med det samme. Det anbefales at færdiggøre disse hurtigst muligt, og helst inden projektet starter. Nogle af aktiviteterne kan tage længere tid at gennemføre, derfor vil det at starte dem tidligere hjælpe med at strømline dit faktiske migreringsprojekt.
Figuren Aktiviteter før migrering nedenfor fremhæver fem specifikke kategorier af aktiviteter, der er relateret til en Webex Calling-migrering.
Forbered
Forretningsmæssige og tekniske krav
Når man planlægger en migrering fra til , er det afgørende at indsamle både tekniske og forretningsmæssige krav grundigt i planlægningsfasen. Dette trin sikrer, at migreringen er i overensstemmelse med din organisations operationelle mål og tekniske muligheder, hvilket minimerer risici og afbrydelser.
Hvorfor det er vigtigt at indsamle krav:
-
Afstemmer forretningsmål: Forståelse af forretningsbehov hjælper med at skræddersy migreringen til at understøtte vigtige arbejdsgange, brugeroplevelse og vækstplaner.
-
Sikrer teknisk kompatibilitet: Tidlig identifikation af tekniske krav forhindrer integrationsproblemer med eksisterende infrastruktur, netværk og endpoints.
-
Letter ressourceplanlægning: Tydelige krav hjælper med at estimere tidslinjer, omkostninger og nødvendige ressourcer præcist.
-
Reducerer risici: Tidlig opdagelse af potentielle udfordringer muliggør proaktive løsninger, hvilket reducerer nedetid og afbrydelser i tjenesten.
Forretningskrav
Typiske forretningskrav omfatter:
-
Antal brugere og placeringer, der skal migreres
-
Ønskede funktioner og tjenester (f.eks. opkaldsrouting, telefonsvarer, konferencer, automatiske omstillinger, opkaldskøer)
-
Overholdelse af regler og sikkerhedspolitikker
-
Budgetbegrænsninger og omkostningsforventninger
-
Brugeruddannelse og supportbehov
-
Migreringstidsplan og overvejelser om forretningskontinuitet.
At indsamle ønskede funktioner og tjenester er et afgørende skridt for at sikre, at det nye system opfylder forretningsbehovene. Når man indsamler disse krav, er det vigtigt ikke kun at overveje, hvad der aktuelt er konfigureret, men også at forsøge at indsamle de faktiske krav fra de forretningsenheder, der skal bruge systemet. Ellers er der risiko for, at planen er baseret på ikke-aktuelle forudsætninger. Sørg for at evaluere yderligere eller forbedrede funktioner, der er tilgængelige i , som muligvis ikke findes i , såsom cloudbaserede opkald, avancerede opkaldskøer og . Dette hjælper med at udnytte de fulde fordele ved cloud-platformen.
Når man evaluerer den nuværende konfiguration i , er det vigtigt at erkende, at ikke alle eksisterende indstillinger muligvis forbliver nødvendige på grund af udviklende krav i løbet af systemets livscyklus. Fokus bør være på kun at identificere og fastholde de konfigurationer, der stemmer overens med de nuværende og fremtidige behov i implementeringen.
Fokuser mere på hvad du har brug for, end hvad du har.
Overholdelse af regler og sikkerhedspolitikker er kritiske overvejelser under migreringen fra til Webex Calling for at sikre, at det nye cloudbaserede kommunikationssystem overholder juridiske, lovgivningsmæssige og organisatoriske standarder.
-
Overholdelse af regler: Organisationer skal verificere, at de overholder branchespecifikke regler såsom GDPR, HIPAA eller SOX, der omfatter krav til databeskyttelse, opbevaring og håndtering, samt landespecifikke krav relateret til dataopbevaring, omgåelse af vejafgifter og medielokalitet.
-
Datasikkerhed: Sikring af, at tale- og signaldata krypteres både under transit og i hvile for at beskytte mod aflytning eller uautoriseret adgang.
-
Adgangskontroller: Definering og håndhævelse af brugergodkendelse, autorisation og rollebaseret adgang for at forhindre uautoriseret brug af kommunikationsressourcer.
-
Revision og overvågning: Implementering af logførings- og overvågningsfunktioner til at spore adgang og brug i forbindelse med compliance-revisioner og undersøgelser af sikkerhedshændelser.
-
Politiktilpasning: Tilpasning af migreringen til eksisterende virksomhedssikkerhedspolitikker, herunder endpoint-sikkerhed, netværkssegmentering og planer for håndtering af hændelser.
-
Leverandørsikkerhedsgaranti: Evaluering af Ciscos sikkerhedscertificeringer og compliance-attesteringer for at sikre troværdighed.
Ved at adressere disse compliance- og sikkerhedspolitikker i planlægningsfasen er det med til at mindske risici, undgå juridiske sanktioner og opretholde integriteten og fortroligheden af kommunikationen under og efter migreringen.
Brugeruddannelse og supportbehov er væsentlige komponenter under migreringen fra til for at sikre en gnidningsløs overgang og brugeradoption. Vigtige overvejelser omfatter:
-
Træningsprogrammer: Udvikle skræddersyede træningssessioner for forskellige brugergrupper (slutbrugere, administratorer, helpdesk-personale) for at gøre dem bekendt med funktioner, brugergrænseflader og nye arbejdsgange.
-
Dokumentation: Tilbyd klare og tilgængelige brugervejledninger, ofte stillede spørgsmål og hurtigreferencematerialer, herunder Nyheder og forskelle ressourcer og trinvise Før- og eftervejledninger (i video- eller hurtigguideformat) for at støtte brugerne i deres tilpasning til den opdaterede oplevelse efter migreringen.
-
Forandringsledelse: Kommuniker ændringer proaktivt for at håndtere brugernes forventninger og reducere modstand.
-
Støttestruktur: Opret et dedikeret supportteam eller en eskaleringsproces til at håndtere brugerproblemer hurtigt under og efter migreringen.
-
Løbende uddannelse: Planlæg løbende træningsopdateringer, når nye funktioner eller opdateringer udgives i .
-
Feedbackmekanismer: Implementer kanaler, hvor brugerne kan rapportere problemer og give feedback for at forbedre trænings- og supportprocesser.
At imødekomme disse trænings- og supportbehov i planlægningsfasen hjælper med at minimere forstyrrelser, øge brugertilliden og maksimere fordelene ved at migrere til .
Tekniske krav
Flere vigtige tekniske krav skal indsamles og dokumenteres for en vellykket migrering fra til , herunder detaljer om:
-
Netværksberedskab og båndbreddekapacitet
En omfattende netværksvurdering er afgørende for at sikre, at din eksisterende infrastruktur kan understøtte det nye Webex Calling-miljø. Denne inkluderer:
-
Båndbreddeanalyse: Evaluering af nuværende og forventet båndbreddeforbrug for at håndtere tale-, video- og datatrafik uden overbelastning.
-
Servicekvalitet (QoS): Implementering af QoS-politikker for at prioritere taletrafik og minimere latenstid, jitter og pakketab.
-
WAN- og internetforbindelse: Verifikation af, at WAN-links og internetforbindelser opfylder kravene til cloudbaserede opkald, herunder redundans- og failover-funktioner.
-
Firewall- og NAT-konfiguration: Sikring af at firewall- og NAT-indstillinger tillader den nødvendige signalering og medietrafik for .
-
-
Integration med eksisterende system
Problemfri integration med eksisterende forretningssystemer er afgørende for brugeroplevelsen og kontinuiteten i arbejdsgangen:
-
Katalogtjenester: Vurdering af integration med en virksomhedsmappe til automatiseret brugerklargøring og -godkendelse.
-
CRM- og forretningsapplikationer: Identificering af integrationspunkter med CRM-systemer og andre forretningskritiske applikationer.
-
Legacy PBX-interaktion: Planlægning af sameksistens eller faseopdelte migreringsstrategier, hvis der forbliver ældre telefonisystemer under overgangen.
-
-
Endpointkompatibilitet og provisionering
Alle slutpunkter, herunder bordtelefoner, softphones og mobile enheder, bør evalueres for kompatibilitet:
-
Enhedsunderstøttelse: Bekræftelse af, at eksisterende IP-telefoner og -enheder understøttes af, eller identifikation af nødvendige udskiftninger.
-
Provisioneringsprocesser: Etablering af automatiserede eller strømlinede provisioneringsmetoder til effektiv onboarding af endpoints.
-
Firmware- og softwareopdateringer: Planlægning af nødvendige opdateringer for at sikre interoperabilitet og sikkerhed.
-
-
Sikkerhedskonfigurationer og krypteringsstandarder
Sikkerhed er altafgørende i cloudkommunikation:
-
Kryptering: Håndhævelse af end-to-end-kryptering til signalering og mediestreams i overensstemmelse med Ciscos bedste praksis for sikkerhed.
-
Godkendelse og adgangskontrol: Implementering af sikre godkendelsesmekanismer (såsom SSO, multifaktorgodkendelse) og detaljerede brugeradgangskontroller.
-
Overholdelse: Sikring af, at løsningen opfylder relevante lovgivningsmæssige og branchemæssige standarder (f.eks. GDPR, HIPAA).
-
Sikkerhedsovervågning: Integration med SIEM-værktøjer og opsætning af advarsler for potentielle sikkerhedshændelser.
-
| Krav | Vigtige overvejelser |
|---|---|
| Netværksberedskab og båndbredde | Båndbredde, QoS, WAN/Internet, Firewall/NAT |
| Integration med eksisterende systemer | Katalog, CRM, PBX, Email/Calendar |
| Endpointkompatibilitet og provisionering | Enhedssupport, klargøring, firmwareopdateringer |
| Sikkerhedskonfigurationer og kryptering | Kryptering, godkendelse, compliance, sikkerhedsovervågning |
| Brugeruddannelse og forandringsledelse | Træningsprogrammer, dokumentation, forandringskommunikation |
| Nummerportabilitet og opkaldsplan | Antal migration/porting, oversættelse af opkaldsplan |
| Tredjepartsintegrationer | Personsøger, kontaktcenter, fax, analoge enheder |
Netværksberedskab og krav
Netværksberedskab er afgørende for en vellykket migrering til enhver cloudbaseret opkaldsløsning som . Dårlig netværksplanlægning kan føre til forringet opkaldskvalitet, afbrudte opkald og utilfredse brugere. Kunder skal udføre en netværksvurdering, inden de migrerer til . Det anbefales at bekræfte netværksbåndbreddetilgængeligheden for den forventede opkaldsvolumen, sikre at kravene til servicekvalitet (QoS) er opfyldt, og forstå de forskellige porte, der skal åbnes i edge-firewallen(e).
Pålidelig netværksforbindelse med tilstrækkelig servicekvalitet (båndbredde, pakketab, RTT) er et grundlæggende krav for at sikre den bedst mulige brugeroplevelse fra ende til anden for alle tale- og videokompatible slutpunkter, klienter og applikationer, der bruger .
Kunder og partnere har adgang til forbindelsesmuligheder ud over Over-the-top (OTT) internet, der kan optimere forbindelsen til også at omfatte Webex Edge Connect. For mere information om Webex Edge Connect-designdetaljer, se Cisco Preferred Architecture for Webex Edge Connect til Webex Meetings, Calling Multi-Tenant og Dedicated Instance.
Kunder kan bruge CScan til netværksvurdering, som giver information om kundens netværkskvalitet, hvor mange opkald der kan etableres, latenstid osv. For mere information om CScan-værktøjet, se Brug CScan til at teste Webex Calling-netværkskvaliteten.
For at sikre, at netværket er klar til migrering til , skal du overveje følgende tjekliste:
-
Båndbreddeplanlægning
Beregn samtidige opkald pr. lokation for at sikre, at du har tilstrækkelig upstream- og downstream-båndbredde og inkluderer plads til anden forretningskritisk trafik og fremtidig vækst.
Tabellen Webex Calling-båndbreddeberegninger viser de opkaldstyper, der er tilgængelige med en implementering, sammen med codec og den maksimale båndbredde, der kræves for hver opkaldstype. Som vist i tabellen Webex Calling-båndbreddeberegninger for opkaldstype kan den nødvendige lydopkaldsbåndbredde for hver opkaldstype beregnes ved hjælp af følgende generelle formel:
Antal forventede samtidige opkald * Båndbredde pr. opkald baseret på codec = Nødvendig netværksgennemstrømning.
Tabel 2. Beregninger af båndbredde for Webex-opkaldstyper Opkaldstyper Codec - båndbredde Båndbreddeberegninger / Bordtelefon -> OPUS - 70 kbps Antal samtidige opkald * 70 kbps = Nødvendig netværksgennemstrømning / Bordtelefon -> Bordtelefon OPUS – 70 kbps Antal samtidige opkald * 70 kbps = Nødvendig netværksgennemstrømning / Bordtelefon -> PSTN via LGW G.711 – 80 kbps Antal samtidige opkald * 80 kbps = Nødvendig netværksgennemstrømning / Bordtelefon -> PSTN via Cloud PSTN (f.eks. Cisco-opkaldsabonnement) G.711 – 80 kbps Antal samtidige opkald * 80 kbps = Nødvendig netværksgennemstrømning / Bordtelefon -> Virksomhed via LGW G.722 – 80 kbps Antal samtidige opkald * 80 kbps = Nødvendig netværksgennemstrømning / Bordtelefon -> telefonsvarerbesked OPUS – 70 kbps Antal samtidige opkald * 70 kbps = Nødvendig netværksgennemstrømning Ved at summere den samtidig krævede netværksgennemstrømning pr. opkaldstype kan det samlede potentielle båndbreddekrav for et specifikt sted bestemmes.
Alle opkaldsben er altid forankret på adgangs-SBC'erne. For at bestemme den nødvendige internetbåndbredde for en given lokation skal ikke kun de interlokationsopkald tages i betragtning, men også opkald inden for lokationen og opkald til og fra en lokal gateway på den pågældende lokation. For eksempel ville et intra-site opkald mellem to MPP-telefoner kræve op til 2 x 70 kbps fuld duplex på lokationens internetadgang.
Tabellen Eksempler på Webex-opkaldsbåndbreddeberegning viser et eksempel på en komplet båndbreddeberegningsøvelse, forudsat at alle enheder er på samme sted.
Tabel 3. Eksempler på beregning af båndbredde for Webex-opkald Opkaldstyper Antal samtidige opkald Samlet båndbredde Webex-appen / Bordtelefon → Webex-app 15 2 * 15 * 70 kbps = 2.100 kbps Webex-appen / Bordtelefon → Bordtelefon 15 2 * 15 * 70 kbps = 2.100 kbps Webex-appen / Bordtelefon → PSTN via LGW 50 2 * 50 * 80 kbps = 8.000 kbps Webex-appen / Bordtelefon → PSTN via Cloud Connect til Webex Calling 0 0 * 80 Kbps Webex-appen / Bordtelefon → Virksomhed via LGW 15 2 * 15 * 80 kbps = 2.400 kbps Webex-appen / Bordtelefon → Webex Calling Voicemail 5 5 * 70 kbps = 350 kbps Samlede opkald / Båndbredde 100 opkald 14.950 kbps / 14,95 Mbps -
Alle båndbreddeværdier i ovenstående tabeller refererer til IP-båndbredde. Linkbåndbredden er højere afhængigt af WAN-indkapslinger.
-
Båndbredden i ovenstående tabeller er til lydopkald. For båndbredde for videoopkald, Webex-appen og MPP 8845/65 Telefoner understøtter H.264-video med en maksimal opløsning på 720p og en maksimal båndbredde på 1.500 kbps pr. opkald. Mængden af båndbredde, der forbruges på et hvilket som helst tidspunkt under opkaldet, vil dog svinge baseret på den variable bithastighed, der er forbundet med videokommunikation.
-
-
Servicekvalitet (QoS)
Implementer QoS-politikker i dit lokale miljø for at prioritere realtidstrafik og sikre, at QoS opretholdes på tværs af switche, routere og firewalls.
-
Mål for latenstid, jitter og pakketab
Følgende tærskler anbefales for optimal talekvalitet, når opkald går Over-the-Top (OTT) og på tværs af internettet:
-
Latens - mindre end 100 ms envejs
-
Jitter - mindre end 10 ms
-
Pakketab - 0,5% eller mindre.
-
-
Firewall og NAT
Sørg for, at firewallen er konfigureret til at tillade trafik som angivet i artiklen, der er tilgængelig på Portreferenceoplysninger for Webex Calling. Derudover skal du tillade adgang til domæner og IP-områder, der er anført i den samme vejledning, og undgå SIP ALG, da det forstyrrer SIP-signalering. Medietrafik via proxyer bør undgås.
-
DNS og NTP
Sørg for korrekt DNS-opløsning af domæner og pålidelige NTP-servere for at synkronisere enhedsure til TLS-certifikatverifikation og logføring.
-
Failover-planlægning
Overvej eksisterende udbyderdataforbindelser (MPLS, SD-WAN osv.), og planlæg generelt direkte internetadgang på hver placering i din implementering. Planlæg for redundante internetforbindelser, hvor høj tilgængelighed er påkrævet. Da du vil bruge cloudbaserede tjenester, er pålidelig internetforbindelse med tilstrækkelig båndbredde et grundlæggende krav. Du bør genoverveje denne overgang, hvis din organisations internetforbindelse(r) generelt ikke er pålidelige med lav latenstid og tilstrækkelig up- og downstream-gennemstrømning.
-
Overlevelsesevne på stedet
Webstedets overlevelsesevne sikrer, at din virksomhed altid er tilgængelig, selvom din netværksforbindelse afbrydes. Site Survivability bruger en gateway i dit lokale netværk til at levere en reserveopkaldstjeneste til lokale slutpunkter i situationer, hvor netværksforbindelsen afbrydes. Overvej stedets overlevelsesevne med en lokal overlevelsesgateway (SGW), hvis forretningskrav kræver kontinuerlig opkald i tilfælde af netværksafbrydelse. For mere information om kontrol af webstedets overlevelsesevne, se Websteds overlevelsesevne for Webex Calling.
Opsæt cloud-forbundet UC
Cloud Connected UC (CCUC) er en cloudbaseret administrations- og analyseløsning, der er designet til at give centraliseret synlighed, administration og indsigt til implementeringer både lokalt (f.eks. Unified CM) og i skyen (cloud). Det fungerer som en bro mellem traditionelle lokale miljøer og Ciscos cloud-tjenester og understøtter organisationer gennem hele migreringsprocessen fra til .
Under overgangen til [navn på udbyder af Unified Communications] spiller CCUC en afgørende rolle i at strømline migreringsprocessen ved at fremme indsamlingen af omfattende data fra den eksisterende Unified Communications-implementering. CCUC hjælper med vigtige overgangsopgaver såsom migrering af enheder, funktioner og brugerkontakter, samt automatisering af firmwareopdateringer til understøttede IP-telefoner. Ved at tilbyde centraliseret overblik og administration hjælper CCUC med at sikre en mere problemfri og effektiv migreringsoplevelse.
Cisco anbefaler på det kraftigste, at CCUC implementeres og implementeres tidligt i overgangsprojektet, ideelt set før eller under forberedelsesfasen. Dette vil give dig den indsigt og de nødvendige muligheder for grundigt at vurdere, lave en opgørelse over og planlægge efterfølgende migreringsaktiviteter og starte din rejse mod fremtidige hybridfunktioner.
Vurdering af det nuværende miljø
En nøgleaktivitet i planlægningen af din migrering er at vurdere det nuværende lokale miljø og den aktuelle implementering. Dette giver indsigt i, hvilke potentielle ændringer der kan være nødvendige for en vellykket overgang til . Det giver dig også mulighed for at vurdere platformens nøgleelementer i sammenligning med den eksisterende lokale implementering. Du kan bruge disse oplysninger til at identificere, hvilke specifikke opgaver der kræves til overgangen, og hvilke ændringer du ønsker at foretage for at opfylde dine forretningsmæssige og tekniske krav og use cases.
Følgende aspekter er vigtige at gennemgå som en del af denne indsats.
Licensering
Det er vigtigt at forstå den nuværende licensstruktur for den eksisterende implementering, når man forbereder sig på at migrere til . Udfør en licensvurdering af følgende områder af din eksisterende Cisco on-premises-løsning.
-
Platform
Evnen til fuldt ud at kunne formulere, hvad der i øjeblikket er licenseret på din kerneplatform, vil være afgørende, når du samarbejder med dit accountteam eller din partner om at bestemme den bedste vej til fleksibel licensering. er licenseret ved hjælp af fleksibel licensering. For mere information om fleksible licenser, se Cisco Collaboration flex plan.
-
Brugere og enheder
Identificér hvilken licenskategori dine eksisterende brugere og enheder kræver. Dette vil blive brugt til at bestemme, hvilken type licens der kræves for brugerne og enhederne. tilbyder flere licenstyper, herunder professionelle og standardlicenser til brugere og professionelle og fællesområdelicenser til arbejdsområder. For yderligere information om enhedslicenser, se databladet, der er tilgængeligt på Enhedslicenser.
-
Lokal gateway
Hvis Cisco Unified Border Element (CUBE) er påkrævet for PSTN-adgang i forbindelse med denne overgang, skal CUBE-licensering også overvejes. Overvejelser vedrørende CUBE-licenser er dækket senere i dette dokument.
Locations/Sites
Antallet og typerne af lokationer (store centrale, regionale, filialer osv.) i din eksisterende implementering bør tages i betragtning, når denne overgang planlægges. En fuld forståelse af de eksisterende implementeringssteder vil hjælpe med strategisk planlægning af en vellykket overgang, især når det gælder at bestemme, hvilke steder der skal migreres, og i hvilken rækkefølge. Det vil være afgørende, når der træffes beslutninger om migrering, at der er en detaljeret forståelse af krav til opkaldsplaner (nummerering, opkaldsvaner, begrænsningsklasser osv.), netværksforbindelse og båndbredde (internet, WAN, LAN) samt PSTN-adgang (lokal eller centraliseret, IP eller TDM) for hver lokation. For yderligere information om almindelige implementeringsmodeller og vigtige overvejelser, se oplysningerne om implementeringsmodeller for samarbejde, der er tilgængelige i Collaboration SRND.
En anden vigtig overvejelse vedrørende implementeringen ved overgang til er placeringstilgængelighed. har forskellige funktioner, abonnementer og enheder, der er tilgængelige afhængigt af, hvor din implementering er placeret. For mere information om geografisk tilgængelighed, se Hvor er Webex tilgængeligt?.
Endelig er det vigtigt at forstå, hvilken indvirkning overgangen til vil have på andre samarbejdstjenester. Baseret på formålet med dette dokument er den generelle antagelse, at hvis eksisterende samarbejdstjenester uden for opkaldsarbejdsbyrden skal opretholdes, forventes overgang til den ovenfor nævnte fase 1-hybridudrillering. Eksempler på samarbejdstjenester, der kan kræve hybrid implementering, omfatter lokale kontaktcentre, der endnu ikke er migreret til Webex kontaktcenter, og tætte integrationer i systemer som personsøgersystemer og fakturering. For mere information om overgangen af yderligere samarbejdsopgaver og -tjenester, se Samarbejdsovergange.
Eksisterende lagerbeholdning devices/clients
Før overgangen påbegyndes, er det vigtigt at lave en opgørelse over dine eksisterende hardware- og software-slutpunkter. Har en komplet liste over enheder types/models, Hardwareversioner, typer og mængder af soft client-operativsystemer vil sikre, at du kan planlægge overgangen af enhederne tilstrækkeligt og afbøde virkningen for de enheder, der ikke kan migreres til cloud-opkald. Opgørelsen bør bruges til at bestemme, hvilke enheder der skal overgås, og hvilke enheder der skal udskiftes inden overgangen.
Bordtelefoner
For audio- og video-bordtelefoner understøttes kun bordtelefonerne i 6800-, 7800-, 8800- og 9800-serien. Dette er en delmængde af de Cisco IP-telefoner, der understøttes med . Der er nogle modeller og versioner af 6800-, 7800- og 8800-telefonerne, som ikke kan bruges med . For mere information om hvilke modeller og hardwareversioner der understøttes, se Understøttede enheder til Webex Calling.
Cisco 6800-serien af IP-telefoner kan ikke opgraderes fra Enterprise-firmware til Multiplatform (MPP) firmware, som er påkrævet for . Derfor skal alle 6800-telefoner, der er registreret til at køre enterprise-firmware, udskiftes med en 6800 MPP-model eller med en anden understøttet telefonmodel.
Cisco 7800- og 8800-serien af IP-telefoner skal opgraderes til Multiplatform Phone (MPP)-firmwaren, før de overføres til og registreres til . For at finde ud af, hvilke 7800- og 8800-modeller og hardwareversioner der understøtter MPP-firmwaren, se Konverter Cisco 7800- og 8800-seriens IP-telefoner mellem Enterprise- og MPP-firmware.
8845, 8865 og 8865NR er udløbet af salg og anbefales ikke at migrere til .
Ældre versioner af 8800-seriens telefoner (8811, 8841, 8851, 8851NR, 8861) anbefales ikke til brug med Webex Calling. Telefoner med hardwareversioner VID 14 eller tidligere vil blive registreret hos, men kan opleve visse ydeevneproblemer på grund af hardwaren.
Bordtelefonerne i 9800-serien kører PhoneOS, som understøtter både og registrering. Derfor kan disse telefoner overgås til uden en firmwareopgradering.
Alle andre IP-telefoner skal udskiftes med telefoner i 6800-, 7800-, 8800- eller 9800-serien, der understøttes af Webex Calling. For mere information om understøttede IP- og bordtelefoner med [] se artiklen på Understøttede enheder til Webex Calling.
Videoslutpunkter
Personlige og rumvideo-slutpunkter, herunder Cisco Board-serien, Room-serien og Desk-serien, kan integreres i SIP-registreringen. Alle disse slutpunkter, der skal lave lyd and/or PSTN-opkald kræver en opkaldslicens:
-
Delte enheder i konferencerum, mødeområder osv. kræver enten en Professional Workspace- eller Workspace-licens.
-
En slutbrugers personlige enhed kræver en professionel eller standardlicens.
Bestem, hvor mange videoslutpunkter der er registreret til og bruges til at foretage lydopkald. Det er muligt, at nogle af videoslutpunkterne kun bruges til at deltage i møder eller foretage SIP-videoopkald. I begge tilfælde skal slutpunkterne stadig migreres, før serverne tages ud af drift, men dette vil hjælpe med at bestemme, hvor mange af dem der skal bruge licenser for fortsat at kunne foretage telefonopkald.
-
Når videoenheder flyttes fra registrering til , ændres URI'en for disse slutpunkter, da de nu er cloud-registrerede.
-
Telefonmodellerne 8845, 8865 og 8875 er personlige videotelefoner, der understøttes med .
Bløde klienter
er den eneste soft-klient, der understøttes af , i modsætning til Unified CM, som understøtter både Webex-appen og Jabber, og er den nye standard soft-klient for slutbrugere.
Afhængigt af den/de implementeringstilstand(er), der er implementeret for Jabber (kun IM, kun telefon, and/or fulde UC-tilstande), skal du muligvis også overveje overgangen til Messaging and/or Mødebelastninger fra Jabber til . Den kan implementeres i telefon-kun-tilstand, hvis den skal bruges som en klient kun til opkald, eller den kan implementeres som den fulde Webex Suite, hvis andre arbejdsbelastninger, f.eks. Webex Messaging, anvendes. and/or Webex Meetings overføres til appen med opkald.
Det forbedrer slutbrugerens oplevelse ved at tilbyde AI-funktioner som f. audio/video intelligens, opkaldstranskription og andet. Se flere oplysninger under https://www.webex.com/all-new-webex.
Før brugere flyttes til dig, skal deres Jabber-klienter overføres til . Du har to muligheder for at fuldføre denne overgang.
-
Før du overfører dem til
-
Når du overfører dem til .
For at lette den indledende overgang til , anbefales det at bruge mulighed 1 og flytte brugerne til med kald først. Dette giver brugerne tid til at blive fortrolige med den nye applikation, mens de stadig bruger den eksisterende lokale opkaldsplatform. Når du er klar til at flytte brugere til , skal du konfigurere deres registrering på cloud-opkaldsplatformen.
For mere information om disse to muligheder, se Migrationsrejse - et eller to trin?.
For en komplet liste over understøttede enheder, se Understøttede enheder til Webex Calling.
Bekræft enhedens berettigelse
Som tidligere nævnt understøtter den en delmængde af Cisco IP-telefoner og kræver en anden firmwaretype til 7800- og 8800-serien af telefoner. Unified CM-telefoner kører Enterprise-firmwaren, mens telefoner kører Multiplatform Phone (MPP)-firmwaren. Det anbefales at kontrollere, hvilke registrerede telefoner der er berettigede til at opgradere til MPP-firmwaren, i forberedelsesfasen. Dette giver dig tid til at udskifte ikke-berettigede telefoner med en af de understøttede telefonmodeller eller til at identificere en alternativ plan, f.eks. at flytte en bruger til kun Webex-appen.
For at hjælpe med at bestemme telefonernes berettigelse har Control Hub et indbygget værktøj kaldet Migrer din telefon til Webex Calling. Når du bruger dette værktøj til at kontrollere enhedsberettigelse, skal du vælge migreringsindstillingen Generer kun enhedslicens.
Denne mulighed giver dig mulighed for at uploade en CSV-fil, der indeholder telefonerne, så du kan kontrollere, om hver telefon er berettiget. Ved at vælge denne migreringsmulighed tilføjes telefonerne ikke, da du stadig er i forberedelsesfasen og ikke er klar til at gøre dette endnu. For yderligere oplysninger, se Overfør din telefon til Webex Calling .
Det er muligt, at nogle af telefonerne vender tilbage med en Ukendt berettigelse. Dette skyldes typisk, at den ikke kan validere visse oplysninger om telefonen i backend-systemet. For telefoner med statussen Ukendt har du to muligheder for at kontrollere, om de er berettigede til at opgradere til MPP-firmwaren.
-
Tjek manuelt hver telefon og bekræft model og hardwareversion (PID VID)
7800/8800 telefonetiket med model- og hardwareversionsoplysninger -
Brug Cisco IP-telefonberedskabsværktøjet
Download værktøjet fra https://github.com/joemar2/mpp_readiness_check.
Dette værktøj er ikke et officielt Cisco-værktøj, og det er heller ikke TAC-understøttet. Den har best-effort support, men er gratis at bruge.
Dette værktøj skal køres på en maskine, der er lokal og kan få adgang til serverne og IP-telefonerne. Den har en mulighed for at aktivere webadgang på IP-telefonerne, hvilket anbefales og er nødvendigt for at få de bedste resultater. Derfor bør den bruges uden for arbejdstiden for at undgå forstyrrelser for slutbrugerne. Værktøjets output leverer en rapport, der viser, hvilke af 7800- og 8800-seriens telefoner der er berettigede til at opgradere til MPP-firmwaren. Fordi den har direkte adgang til telefonen, kan den verificere de Ukendte enheder, der blev rapporteret fra Control Hub-værktøjet.
Rapport om Cisco IP-telefonparathedsværktøj
Brugere
Et af de vigtigste forberedelsestrin for at sikre en vellykket migrering er korrekt brugerprovisionering. Du skal planlægge ordentligt for alle brugere, selvom du foretager en faseopdelt migrering. Brugere skal være konfigureret til et af følgende:
-
Implementering af med opkald
-
Implementering af med
-
Konfiguration af tjenester for en bruger
-
For at gøre brugere søgbare i telefonbogen (klik for at ringe, brugerkontaktoplysninger, søgning i telefonbog).
Det anbefales, at du provisionerer alle brugere før eller ved starten af dit projekt. Dette inkluderer brugere, der stadig bruger Unified CM til deres opkaldsplatform, som er uafhængig af deres opkaldsenhed (IP-telefon, Jabber osv.). Efterhånden som brugerne migreres til (and/or den ) du vil opdatere deres licenser for at aktivere de tjenester, de har brug for. Ved at klargøre alle virksomhedsopkaldsbrugere, før overgangen starter, giver det en bruger, der er skiftet til eller , mulighed for at søge i telefonbogen efter en virksomhedsopkaldsbruger, der stadig er på Jabber. and/or på. Dette sikrer, at brugere, der er blevet overført, kan finde andre brugeres kontaktoplysninger og ringe til dem ved hjælp af opslag i telefonbogen.
Figuren katalogsøgning viser et eksempel på en bruger, der søger efter en anden bruger. Søgeresultaterne viser brugerens kontaktoplysninger og kan være for en bruger, der stadig er på Jabber, og/eller for en bruger, der er skiftet til and/or .
Bestem derefter, hvilke af de eksisterende lokale opkaldsbrugere der skal overføres til . Hvis alle eller et stort antal brugere skal overgå til en anden ordning, anbefales det at flytte brugerne i grupper for at sikre, at projektteamet, IT-personalet og supportpersonalet er i stand til at håndtere overgangen og eventuelle problemer, der måtte opstå. Du bør også afsætte tid til at give indledende information og træningssessioner for at forberede brugerne på denne overgang. Brugerovergangsgruppering kan udføres baseret på en række kriterier, herunder den placering eller det websted, som brugerne er tildelt, brugernes afdelinger eller endda brugertyper (vidensarbejdere, ledere, mobile medarbejdere osv.).
Hvis brugerne i implementeringen for eksempel er fordelt på tre hovedlokationer, New York (NYC), San Francisco (SFC) og Research Triangle Park (RTP), kan en brugerovergangsplan se ud som den plan, der er skitseret i tabellen Brugerovergangsplan efter lokation.
| Brugerwebsted / beliggenhed | Information og træningssessioner før overgangen | Overgangsperiode | Støtte efter overgangen |
|---|---|---|---|
| NYC (1.525 brugere) | Ugen fra 1. april | 15. april – 27. april | Ugen der starter den 29. april |
| SFO (1.600 brugere) | Ugen fra den 6. maj | 20. maj – 31. maj | Ugen fra den 3. juni |
| RTP (1.275 brugere) | Ugen fra den 3. juni | 17. juni – 28. juni | Ugen fra 1. juli |
En anden vigtig faktor er at overføre brugere, der har afhængigheder mellem hinanden, sammen. Dette kan omfatte, men er ikke begrænset til, følgende:
-
BLF-overvågning
-
Samme jagt pilot/group
-
Del linjer
-
Del af den samme opkaldsbesvarelsesgruppe
-
Brug af de samme parkerede opkaldsnumre
-
Samtaleanlæg
-
Admin/Exec.
Du kan gennemgå konfigurationen (GUI eller eksport) eller bruge værktøjet Migration Insights til at identificere de brugergrupper, der har disse afhængigheder.
PSTN-forbindelse
kan få adgang til PSTN på tre måder: Cisco-opkaldsabonnementer, Cloud Connect til (tidligere Cloud Connected PSTN) og lokal PSTN (lokal gateway). En enkelt placering som defineret i kan dog kun tildeles en enkelt PSTN-indstilling.
Lokalt PSTN med en lokal gateway (LGW) er en væsentlig del af overgangsstrategien. Det giver forbindelse mellem den lokale implementering and/or PSTN og platformen understøtter både Cisco og certificerede tredjeparts sessionsgrænsekontrollere (SBC), der kan bruges som lokal gateway. For den seneste liste over understøttede SBC'er, se Liste over understøttede SBC'er.
Understøtter op til 250 samtidige opkald fra en enkelt lokal gateway, der er registreringsbaseret, og mere end 250 samtidige opkald fra en enkelt lokal gateway, der er certifikatbaseret. Certifikatbaserede lokale gateways kan understøtte op til 6500 samtidige opkald, men dette er baseret på den type forbindelse, som den lokale gateway har (Over-the-Top vs. interconnect peering) og den SBC-model, som den lokale gateway er implementeret på. Disse grænser er i bund og grund standardantalgrænsen for både lokale gateway-baserede PSTN-opkald og intersite-opkald mellem og slutpunkter. For yderligere information, se Kom godt i gang med lokal gateway.
Alle opkald, der overstiger denne grænse, afvises med en 403 Forbudt. Kommandoen show call active voice kan køres på den lokale gateway når som helst for at bestemme det samlede antal aktive opkald.
Dårlige netværksforhold mellem en lokal gateway og adgangs-SBC'en kan begrænse signalforbindelsens ydeevne, hvilket fører til en endnu lavere grænse for samtidige opkald. Envejslatensen mellem den lokale gateway og datacentret bør ikke overstige 100 ms, og jitteren bør være mindre end 10 ms, mens pakketab er mindre end 0,5 %.
Funktioner & brug af funktioner
Når man vurderer det nuværende miljø, er det vigtigt at identificere og gennemgå, hvilke funktioner der er konfigureret. Derudover er det vigtigt at forstå brugen af funktionerne, så du kan (re)definere dine forretningsmæssige og tekniske krav til din implementering.
For at bestemme, hvilke funktioner der er konfigureret, skal du analysere konfigurationen. Dette er alle statiske data, der angives, når en funktion eller indstilling konfigureres på systemet. Følgende muligheder kan bruges til at fuldføre denne analyse:
-
Gennemgå konfigurationen i administratorgrænsefladen
-
konfigurationseksport -- masseeksport eller AXL
-
Værktøj til migreringsindsigt (anbefales)
-
Cisco-værktøjer fra tredjepartspartnere (anbefales).
For at analysere funktionsudnyttelsen effektivt er det vigtigt at undersøge dynamiske systemdata såsom udnyttelse, registreringer og opkaldsaktivitet. Forskellige analytiske værktøjer og dashboards giver indsigt i disse målinger, hvilket muliggør en omfattende forståelse af systemets ydeevne og kapacitet, hvilket understøtter informeret beslutningstagning under migrerings- og optimeringsindsatsen. Følgende muligheder kan bruges til at udføre denne type analyse:
-
Gennemgang af rå CDR-poster
-
Gennemgang af Unified CM RTMT-data
-
Migration Insights-værktøj ved hjælp af CDR-data
-
Gennemgang af cloud-forbundne UC-analyser i
-
Opkaldsvolumen
-
Registrerede slutpunkter
-
(CAC) placeringer
-
Udnyttelse af bagagerummet.
-
-
Cisco tredjepartspartnerværktøjer.
Cisco anbefaler at starte med Webex Control Hub Migration Insights-værktøjet til denne analyse. Du importerer din eksporterede .TAR-fil og Unified CM CDR-filerne (valgfrit, men påkrævet til analyse af funktionsudnyttelse) til værktøjet. Værktøjet genererer følgende CSV-baserede rapporter, der kan bruges til at starte analysen:
| Rapportnavn Rapportbeskrivelse |
|---|
| ImportedDataBulk.csv Alle brugere og enheder fra Unified CM-data |
| DeviceEligibility.csv Identificerer enheder, der er berettigede til at migrere til Webex Calling (IP-telefoner, Room OS-enheder, ATA'er og tredjeparts) |
| DevicePoolNumbers.txt Liste over alle numre i en bestemt enhedspulje |
| HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv Detaljer om enheder og brugere, der skal migreres sammen, baseret på konfiguration af delte linjer, Hunt Pilot, opkaldskø, opkaldsparkering og opkaldsbesvarelsesgruppe |
| HuntGroupMigrationInsight.csv Detaljeret information om tildelte jagtlinjer, linjegrupper og tilknyttede agenter |
| SharedlineGroupMigrationReport.csv Oversigt over, hvordan telefonnumre (telefonnummer) deles mellem brugere |
| Rapportnavn Rapportbeskrivelse |
|---|
| FeatureUsageBasedDeviceEligibilityReport.csv Oplysninger om berettigelse til enhedsmigrering baseret på funktionsbrug |
| FeatureUsageWithLastUsageDateReport.csv Brugsantal for antallet af gange, huntpilot(er) og opkaldskø(er) er blevet kaldt sammen med den seneste brugsdato. |
| UserWorkspaceLastUsage.csv Sidste brugsdato for brugere og arbejdsområder for både softwareklienter og fysiske telefoner |
| DIDUsageReport.csv DID-brug for både tildelte og ikke-tildelte DID'er |
For yderligere oplysninger om rapporterne Migrationsindsigt, se Migrationsindsigt.
Hvis du har brug for flere oplysninger om funktionerne og brugen efter at have gennemgået oplysningerne i Migration Insights-rapporterne, anbefaler Cisco at overveje et af Ciscos migreringsværktøjer fra tredjepartspartnere. and/or for at gennemgå konfigurationerne i den grafiske brugergrænseflade eller i konfigurationseksportdataene.
Cisco-integrationer: Unity Connection UCCX UCCE
Voicemail er en integreret del af tilbuddet og indbygget i løsningen. Kan ikke integreres med en lokalbaseret voicemail-løsning som f.eks. Unity Connection eller Unity Connection Express. Derudover er der ingen indbygget måde at migrere eksisterende Unity-forbindelses voicemail-beskeder eller hilsner til den indbyggede voicemail-tjeneste, der er tilgængelig med . Nogle af Ciscos tredjepartspartneres migreringsværktøjer har funktioner til at migrere nogle af disse data. For mere information om voicemail for , se Konfigurer og administrer voicemail-indstillinger for en Webex Calling-bruger.
understøtter også delte voicemail- og faxpostkasser. For mere information, se Administrer en delt voicemail og indgående faxboks til Webex Calling.
har en indbygget automatisk assistentfunktion, der er inkluderet som en del af kerneplatformen. Denne funktion muliggør overgangen af din Unity Connections opkaldshåndterings- og automatiske svarfunktioner. Control Hub-værktøjet, Migrer funktioner fra Unified CM, understøtter migrering af Unity Connection-konfigurationer til automatiske svarfunktioner. For mere information om brugen af dette værktøj, se Migrering af enheder og funktioner fra Unified CM til Webex Calling.
Optagelse af opkald
inkluderer to muligheder for optagelse af opkald uden ekstra omkostninger.
-
Webex-opkaldsoptagelse
-
Dubber Go-optagelse (partnertilbud) - en integration mellem og dubber, hvor alle optagede medier opbevares sikkert i skyen.
inkluderede optagelsesmuligheder tabellen fremhæver nogle nøglefunktioner i de to opkaldsoptagelsesmuligheder, der er tilgængelige uden ekstra omkostninger.
| Webex | Dubber Go |
|---|---|
| Tilgængelig for alle brugere | Tilgængelig for alle brugere |
| Ubegrænsede optagelser | Ubegrænsede optagelser |
| 1 års opbevaringsperiode* | 30-dages opbevaringsperiode |
| 100 GB lagerplads pr. organisation | - |
| Compliance-medarbejdere kan få adgang til og administrere opkaldsoptagelser | - |
| API'er til at administrere optagelser | - |
Administratorer kan konfigurere og administrere brugernes adgang til deres opkaldsoptagelser
|
Kun brugere kan få adgang til og administrere deres optagelser
|
Hvis din organisation har brug for yderligere optagelsesfunktioner, f.eks. optagelse af opkald i henhold til reglerne, længere opbevaringsperioder, mere lagerplads, AI-analyse, and/or Administratoradgang, betalte tilbud eller tilføjelser findes fra både Cisco og tredjepartsudbydere af optagelser. For mere information om optagelsesudbydere, konfigurationer og tilføjelsespartnertjenester, se Administrer opkaldsoptagelse for Webex Calling.
Tredjepartsintegrationer
understøtter en rækketredjepartsintegrationer, herunder, men ikke begrænset til, SBC'er til lokale gateways, IP-telefoner, intercom-telefoner, Speaker/Pagers, ATA'er osv. Ud over dissetredjepartsenheder understøtter Webex Calling forskelligetredjepartsløsninger til kundesupport, analyser , optagelse, fakturering osv . For mere information omtredjepartsløsninger , se Webex App Hub.
Planlæg
Projektplan på overordnet niveau
Når man udvikler en overordnet projektplan for migrering fra til , er det vigtigt at etablere klare faser og milepæle, der stemmer overens med både forretningsmål og tekniske krav. Planen bør begynde med en omfattende vurderingsfase, herunder indsamling af detaljerede tekniske og forretningsmæssige krav, samt identifikation af interessenter og definition af succeskriterier. Vigtige overvejelser omfatter ressourceallokering, tidslinjeestimering, risikostyring og kommunikationsstrategier for at sikre, at alle parter er informeret og engageret under hele migreringen. Derudover bør planen indeholde valideringskontrolpunkter såsom pilottest og fasede udrulninger for at minimere forstyrrelser og give mulighed for justeringer baseret på feedback.
Eksempler på elementer, der kan inkluderes i projektplanen, er:
-
Definition af omfanget af migreringen (f.eks. hvilke brugere, enheder og funktioner der skal overgå)
-
Planlægning af træningssessioner for slutbrugere og supportteams
-
Koordinering af netværksberedskabsvurderinger, og
-
Planlægning af overgangsaktiviteter med alternative muligheder. Det er også vigtigt at integrere compliance- og sikkerhedsgennemgange samt support- og optimeringsfaser efter migrering.
Ved at strukturere projektplanen med disse overvejelser kan organisationer bedre håndtere kompleksitet, reducere risici og opnå en mere gnidningsløs overgang til .
Migrationsrejse - et eller to trin?
kræver, at brugerne bruger softklienten til deres opkald. Derfor, hvis nogen brugere stadig bruger , har du to muligheder for, hvornår du kan flytte dem til . Du kan enten udføre en brugermigrering i ét trin eller en brugermigrering i to trin.
Valgmulighed 1: Brugermigrering i ét trin
I en enkelt trinsmigrering overgår brugerne fra til , samtidig med at de overgår fra Unified CM til . Denne mulighed er typisk for kunder med et lille antal brugere, der skal migreres, og som kan administrere flytning af både brugerens softklient og opkaldstjeneste til på samme tid. Figuren Brugerens opkaldstjeneste, softklient & Telefonen migrerer til på samme tid nedenfor fremhæver denne type migrering. Med denne mulighed vil en bruger have følgende udført på samme tid:
-
Opkaldstjenester flyttet fra til
-
Telefonnumre og lokalnumre flyttet fra til
-
Softklient overført fra Jabber til - vil registrere sig til
-
Telefonregistrering flyttet fra til.
Dette kan stadig være en faseopdelt migrering, hvor grupper af brugere flyttes på forskellige tidspunkter, men når hver bruger flyttes, sker alt dette på samme tid.
Valgmulighed 2: Brugermigrering i to trin
Den anden tilgang er en migration i to trin. I trin 1 overføres brugerne fra til , men forbliver aktiveret for opkaldstjenester. I trin 2 flyttes brugerne derefter fra Unified CM til . Denne indstilling anbefales til større kunder, der ønsker at administrere ændringer af slutbrugeren og ønsker at adskille brugerens ændring af softklienten fra ændringen af den kaldende tjeneste. Følgende figur Migrer softklient; migrer derefter opkaldstjeneste, softklient & telefon til Webex Calling nedenfor fremhæver denne type migrering.
Trin 1
-
Softklient overgået fra til - vil registrere sig til .
Trin 2
-
Opkaldstjenester flyttet fra til .
-
Telefonnumre og lokalnumre er flyttet fra til .
-
registreringen er flyttet fra til.
-
Telefonregistrering flyttet fra til.
Dette kan stadig være en faseopdelt migrering, hvor grupper af brugere flyttes på forskellige tidspunkter i begge trin.
Den valgmulighed, du vælger, afhænger af, hvordan du vil administrere dine brugeres overgang til og . Anbefalingen er at tage det i etaper (mulighed 2). Dette giver dig mulighed for at minimere slutbrugerens ændringer på én gang og fordele indsatsen på tværs af forskellige dele af projektet. Hvis du foretrækker kun at have brugerne påvirket én gang, er det også muligt at bruge mulighed 1.
Når man ser på den anbefalede rejse (mulighed 1), Jabber til Webex-appens overordnede overgangskort figuren nedenfor viser overordnet overgang for trin 1.
I dette trin overføres brugerne fra Jabber til for alle deres opkaldstjenester. Opkaldsplatformen er dog stadig Unified CM, og de vil registrere sine opkaldstjenester til . Som det ses i figuren Jabber til Webex-appens overordnede overgangskort ændres den lokale infrastruktur ikke, og den fungerer på samme måde som Jabber. Den eneste ændring er, at der kræves en forbindelse ud til .
For mere information om denne overgang, se Jabber til Webex overgangskort og implementeringsvejledning under klientafsnittet på siden Samarbejdsovergang.
Overgangskort på højt niveau fra Unified CM til Webex Calling Figuren er overgangen på højt niveau fra til . Dette er trin 2 af den anbefalede rejse.
Hvis du beslutter dig for at bruge et-trins-metoden, gælder dette også.
I dette trin overgås brugerne til grupper. På dette tidspunkt begynder brugerne at bruge dem til deres opkaldstjenester, opkaldsregistrering og IP-telefonregistrering.
Da brugerne flyttes i grupper, vil Enterprise-brugere blive delt mellem de to opkaldsplatforme under overgangen. Fase 1 i Unified CM til Webex Calling overgangskort på højt niveau figur viser denne tilstand. I denne fase er det nødvendigt at planlægge, hvordan opkald mellem brugere på de to platforme skal håndteres, og hvordan PSTN-opkald skal dirigeres. Hver gang en gruppe brugere overgår til , vil opkaldsplaner og opkaldsrouting være påkrævet på og den/de lokale gateway(er).
Når alle brugere, softklienter og enheder er blevet overført til (fase 2), kan al lokal UC-infrastruktur fjernes og tages ud af drift.
Design
Valg af region
er tilgængelig globalt og leveres fra redundante datacentre i flere regioner: USA (Dallas, Chicago), Canada (Vancouver, Toronto), Europa (Frankfurt, Amsterdam), Storbritannien (London, Manchester), Australien (Melbourne, Sydney), Japan (Tokyo, Osaka), Saudi-Arabien (Riyadh, Jeddah) og Indien (Mumbai, Chennai). Medie-PoP'erne leverer medietjenester for at optimere mediernes returtransporttider. Datacenteret i Singapore bruges for eksempel til at optimere returtransporttider for medier for kunder i asiatiske lande, hvor returtransporttiderne til enten Australien eller Japan kan være suboptimale. Datacentrene er forbundet med hinanden af et multi-gigabit og fuldt redundant backbone. Figuren globalt distribuerede datacentre viser en oversigt over alle datacentre. For den seneste liste over tilgængelige datacentre, se Datacenterplaceringer til Webex Calling.
Hver kunde er provisioneret på en af instanserne. Alle klargøringsoplysninger for den pågældende kunde gemmes i den pågældende instans, og SIP-signaleringen fra alle slutpunkter og lokale gateways, der er klargjort for den pågældende kunde, er knyttet til den instans, kunden er klargjort på. Da det er svært at ændre det oprindelige valg af region, er det vigtigt at overveje alle relevante faktorer som en del af beslutningsprocessen, der fører til valget af region. For at undgå for stor forsinkelse i signaleringen frem og tilbage er det vigtigt at beslutte tidligt i overgangsprocessen, hvilken instans der skal bruges. Cisco anbefaler at vælge den instans, der giver de laveste signaleringstider for det største antal brugere i installationen.
For tilgængelighed i forskellige lande, se Hvor er Webex tilgængeligt?.
Placeringer
For at forberede tildelingen af lokationer skal de nødvendige oplysninger for alle migrationsmållokationer indsamles. De nødvendige oplysninger for hver lokation er opsummeret i Oplysninger, der skal indsamles for hver lokation.
| Oplysninger | Kommentar |
|---|---|
| Udvidelsesområde(r) | Hver placering kan have udvidelser, der starter med forskellige cifre. Et ciffer skal være til rådighed for styrecifferet for opkald mellem lokationer (f.eks. 8) og et for PSTN-styringscifferet (f.eks. 9). Intet udvidelsesområde kan starte med nogen af disse to cifre. Alle udvidelsesområder for alle lokationer skal være af samme længde. |
| DID-område(r) | - |
| PSTN-styringsciffer | - |
| Webstedskode | Alle sitekoder for alle lokationer skal være unikke og have samme længde. |
| Hovednummer | Når en lokation oprettes, skal der oprettes to DID'er. Et som hovednummer (for eksempel til at blive tildelt en automatisk omstillingstjeneste) og et til telefonsvarerportalen. Tildel ét DID til telefonsvarernummeret. |
| Voicemail-nummer | |
| Antal licenser | Nødvendige licenser efter type, herunder Standard, Professionel, Arbejdsområde, Ruteliste, Udgående Opkaldsplan. |
| Samtidige opkald i travlheden | Summen af samtidige opkald mellem enheder og mellem enheder og den lokale gateway (PSTN og opkald til enheder). Nødvendig for at bestemme den nødvendige internetadgangsbåndbredde. |
| Land | - |
| Tidszone | - |
| Sprog | - |
| Kontakt (navn, telefon, e-mail) | - |
| Adresse (Gadeadresse, By, Stat, Postnummer) | - |
| Fysisk afsendelsessted for nødtjenester til slutpunkter | Enhedens afsendelsessted, der bruges til nødopkald, omfatter generelt følgende: bygningsadresse, bygningsadresse + etagenummer, bygningsadresse + lejlighedsnummer eller bygningsadresse + etagenummer + office/cubical antal. |
| Unik fysisk netværksplacering pr. enhed for nødtjenester | Fysisk netværksplacering til nødopkald omfatter generelt følgende: skifte / switchport til kablede enheder, trådløst adgangspunkt (AP) Basic Service Set Identifiers (BSSID'er) til trådløst tilsluttede enheder, and/or Lokale IP-undernetværk til slutpunktsenheder. |
PSTN
Når kunderne designer en implementering, har de tre primære PSTN-forbindelsesmuligheder: Cisco Calling Plans (en cloud-leveret PSTN-tjeneste administreret af Cisco), Cloud Connected PSTN Providers (CCPP, hvor udbydere leverer PSTN-tjeneste via skyen) og on-premises PSTN (hvor lokale gateways forbinder virksomhedsnetværket til PSTN'et). Med introduktionen af PSTN-trunking til hybridinstallationer (for mere information, se PSTN-trunking til hybrid Webex Calling-installationer på PSTN-trunking) får organisationer yderligere fleksibilitet i deres migreringsmetode. Denne funktion gør det muligt for kunder at flytte deres PSTN til CCPP i starten af overgangsprocessen og begynde overgangen til cloud-PSTN for brugere, samtidig med at CCPP udnyttes til at opretholde PSTN-tjenesten for brugere, der forbliver på Cisco under en faseopdelt migrering.
Denne hybride tilgang giver organisationer mulighed for at flytte udvalgte brugergrupper til skyen først, uden straks at skulle omstrukturere hele deres telefonimiljø. Det introducerer dog yderligere kompleksitet og risiko, især omkring tilpasning af eksisterende opkaldsroutinglogik til at understøtte den nye arkitektur. Interoperabilitet med ældre applikationer, såsom faxservere, kontaktcentre eller personsøgersystemer, kræver også nøje overvejelse. Vigtige tekniske udfordringer kan omfatte at sikre problemfri end-to-end codec-forhandling og DTMF (Dual-Tone Multi-Frequency)-signalering på tværs af det blandede miljø, samt validering af kompatibilitet med specialiserede telefonifunktioner. Korrekt planlægning og testning er afgørende for at minimere afbrydelser og opretholde pålidelige taletjenester gennem hele migreringsprocessen. Derudover er kommercielle overvejelser vigtige, da hybrid trunking kræver en brugslicens, der er baseret på antallet af samtidige opkald mellem det lokale miljø og Cloud Connected PSTN Provider (CCPP).
Alternativt kan organisationer vælge at beholde deres lokale PSTN-forbindelse i hele overgangsfasen. I dette scenarie kan migrering til CCPP udføres på to måder: som en enkelt, koordineret overgang for alle brugere og lokationer, når migreringen er fuldført, eller trinvis, hvor PSTN-migrering sker pr. lokation, efterhånden som brugerne flyttes til . Denne tilgang kan hjælpe med at strømline sameksistens og opretholde kontinuitet for ældre integrationer, men den introducerer adskillige operationelle kompleksiteter. Blandt disse er udfordringer relateret til nummerportering, såsom behovet for præcis koordinering af nummerporteringsordrer, potentielle forsinkelser og udbyderpålagte begrænsninger, såsom et loft over antallet af samtidige porteringsanmodninger eller begrænsninger på portering af delmængder af store nummerblokke. Organisationer skal omhyggeligt planlægge deres PSTN-overgangsstrategi og tage højde for disse logistiske overvejelser for at undgå afbrydelser i tjenesten og sikre en problemfri migreringsoplevelse.
Figuren Migrering til CCCP ved start vs. bevaring af lokalt PSTN viser de to PSTN-migreringsmuligheder, der er forklaret ovenfor. Illustrationen til venstre viser scenariet, hvor alle lokale brugere og applikationer forbruger Cloud Connected PSTN-tjenester via en lokal trunk og en lokal gateway, der forbinder det lokale netværk med [navn], mens illustrationen til højre viser scenariet, hvor det eksisterende lokale PSTN forbliver på plads, og brugere på Webex Calling bruger lokalt PSTN via den lokale gateway-forbindelse mellem det lokale netværk og [navn]. Under overgangen kan lokationer skiftes til at bruge Cloud Connected PSTN.
I begge scenarier bruger opkald mellem lokalt netværk og brugeren den lokale gateway-forbindelse. Forbindelsen mellem den lokale enhed og skal designes og dimensioneres i overensstemmelse hermed baseret på det forventede antal samtidige opkald og den nødvendige redundans.
Opkalds plan
For at opnå problemfri interoperabilitet mellem og under migreringsperioden skal der udvikles og implementeres en omfattende arkitektur for opkaldsplaner på tværs af begge platforme. Dette design med to platforme for opkaldsplaner sikrer ensartet opkaldsrouting, nummeroversættelse og funktionstransparens, hvilket gør det muligt for brugere på begge systemer at kommunikere uden forringelse af tjenesten eller forstyrrelser i brugeroplevelsen i hele sameksistensfasen.
Lokal opkaldsplan ind
Under overgangen skal der foretages ændringer for at muliggøre sameksistens af enheder, der er registreret på Unified CM og på virksomhedens opkaldsplan, så mindst følgende krav kan opfyldes:
-
+E.164 opkald fra til
-
Lokalnummeropkald fra til (intra-site, men også inter-site, hvis lokalnummerintervallerne er unikke)
-
Forkortede opkald mellem lokationer fra til
-
Tvungen opkald på nettet fra til
-
Tilbagekald fra biblioteket med ubesvarede opkald til destinationer på
-
PSTN-opkald fra til PSTN, hvis der under overgangen bruges lokal PSTN til
-
PSTN-opkald fra til hvis PSTN-trunking til hybridinstallationer bruges under overgangen til at give PSTN-adgang til lokale brugere via Cloud Connect til
-
Tvunget online fra til
-
Lokalnummer ringer fra til (inter-site).
Hvis nogen af ovenstående ikke understøttes som opkaldsvaner før overgangen, f.eks. hvis der ikke findes nogen forkortet opkaldsvane mellem lokationer, behøver de ikke nødvendigvis at blive introduceret under overgangen.
Figuren Bedste praksis for opkaldsplan viser den bedste praksis for opkaldsplantilgang som beskrevet i Foretrukken arkitektur til Cisco Collaboration 12.x Enterprise On-Premises-implementeringer, CVD. Nøgleegenskaber ved denne tilgang inkluderer:
-
Enkelt partition til +E.164 telefonnummer
-
Kernerouting baseret på +E.164 rutemønstre
-
Normalisering af alle opkaldsvaner +E.164 ved hjælp af oversættelsesmønstre
-
Brug af oversættelsesmønster, der kalder søgerumsarv (indstilling Brug oprindelseskaldende søgerum indstillet på oversættelsesmønstre).
For eksempel PSTN-opkald (9+1+10D) fra en enhed i SJC, der er klargjort med linjekaldssøgningsrum SJCInternational vil først blive matchet af 9.1[2-9]XX[2-9]XXXXXX oversættelsesmønster, der normaliserer det opkaldte nummer til +E.164. Det sekundære opslag bruger derefter det samme kaldende søgeområde SJCInternational igen (kalder søgeområdearv) og +E.164-digit strengen vil enten blive matchet af en +E.164 katalognummer i DN partitionen eller via et af PSTN-rutemønstrene i USPSTNNational eller SJCPSTNLocal partitionen. Forkortede opkaldsvaner inden for og mellem steder implementeres af oversættelserne i ESN og SJCtoE164 partitionerne. Selvom ESN partitionen er en global partition (tilgængelig for telefoner på alle lokationer), er SJCTOE164 partitionen kun tilgængelig for brugere på lokation SJC. Dette antager overlappende udvidelsesområder.
Det første skridt til at aktivere opkald fra til er at sørge for, at +E.164 Destinationer bliver rutet i overensstemmelse hermed. Dette kan opnås ved at tilføje en partition til opkaldsplanen, tilføje +E.164 rutemønstre for alle destinationer til den pågældende partition, og endelig tilføjelse af partitionen til alle kaldende søgeområder, der repræsenterer tjenesteklasser, som skal kunne nå . Det er nødvendigt at oprette en dedikeret partition for at muliggøre oprettelse af en differentieret tjenesteklasse for opkald, der stammer fra . For at undgå opkaldsløkker bør søgeområdet for indgående opkald på trunk'en fra den lokale gateway ikke have adgang til partitionen.
Som vist i figur +E.164 routing til Webex Calling, for at aktivere routing fra til for en placering med +E.164 DID-område +1 221 555 2XXX og lokationskode 121, et hasterutemønster der matcher dette +E.164 område skal tilføjes til partitionen.
Hvis der ikke kræves et stedspecifikt valg af lokal gateway, kan rutemønstre, der peger på en enkelt rutegruppe, i stedet for at bruge en ruteliste med en lokal rutegruppe som destination, klargøres med den lokale gateway som det eneste medlem, og derefter peger rutemønstrene på en enkelt ruteliste med denne ene rutegruppe som eneste indgang.
For at muliggøre kortnummeropkald mellem lokationerne tilføjes det nødvendige rutemønster 8121.2XXX til partitionen. For at websteder skal overgå til et opkaldsnormaliseringsmønster 8121.2XXX, der normaliserer ESN-opkald til +E.164 findes muligvis allerede i ESN partitionen. I så fald synes 8121.2XXX at være redundant, men så snart alle DN'er for den respektive placering er blevet migreret til 8121.2XXX opkaldsnormaliseringsoversættelsesmønsteret fjernes, og derefter muliggør 8121.2XXX rutemønsteret ESN-opkald, selv for brugere, der kun bruger lokalnumre i det pågældende område.
Med disse ændringer i opkaldsplanen kan opkald til stedet ikke blot foretages ved at ringe til forkortede interlokationsnumre, men også +E.164. Internationale og nationale PSTN-opkald er også mulige, fordi disse opkaldsvaner først normaliseres til +E.164 gennem de allerede eksisterende opkaldsnormaliseringsoversættelsesmønstre og derefter blive dirigeret til ved at matche +E.164 rutemønster i partitionen.
De +E.164 Rutemønstermatchning på lokationens DID-interval kan klargøres, mens alle DID'er stadig hostes på . Den bedste algoritme til matchmønstermatchning sikrer, at når et nummer, der er hostet på, ringes op, så +E.164 Det katalognummer, der er provisioneret på, er et bedre match end jokertegnet +E.164 rutemønster, der peger på , så opkaldene viderestilles til en linje på og ikke sendes til .
opkaldsplan
Hver bruger er tildelt en udvidelse and/or -en +E.164 telefonnummer. Forlængelselængden er en fast global indstilling: Alle udvidelser i en implementering har samme længde. Lokalnummeropkald kan bruges mellem brugere både inden for en lokation og mellem lokationer. Forkortet opkald mellem lokalnumre (sidstnævnte tilfælde) fungerer kun, hvis det opkaldte lokalnummer er unikt.
Hvis forkortede opkald mellem lokationer er et krav, men der er overlap mellem lokalnumre, der er tildelt på forskellige lokationer, skal der oprettes en virksomhedsspecifik nummerplan ved at give lokalnumrene en adgangskode (en lokationskode) foran. For yderligere information, se Foretrukken arkitektur til Cisco Collaboration 15 lokale implementeringer, designoversigt tilgængelig på Cisco Collaboration foretrukne arkitekturer.
Lokalnummerets længde, opkaldsadfærden for interlokationsopkald, præfikslængden for interlokationsopkald og styrecifferet i routingpræfikset for interlokationsopkald konfigureres i indstillingerne for opkaldstjenesten i :
-
Længde af præfiks til placeringsrute: Præfikslængde inklusive styrecifferet. Kun påkrævet, hvis en virksomhedsnummerplan skal etableres som alternativ forkortet virksomhedsopkaldsrutine mellem lokationer.
-
Styringsciffer i rutepræfiks: Styreciffer for forkortet virksomhedsopkaldsrutine. Overlap med det første ciffer for enhver lokation og udgående opkaldscifre for lokationen bør undgås. Kun påkrævet, hvis en virksomhedsnummerplan skal etableres som alternativ forkortet virksomhedsopkaldsrutine mellem lokationer.
-
Intern forlængerlængde: Standardlængde på forlængere. Kan have en hvilken som helst værdi mellem to og ti.
Når der kræves opkald via lokalnummer eller opkald ved hjælp af virksomhedens signifikante numre (styringskode, lokationskode, lokalnummer) fra en lokal opkaldskontrol til , og den lokale opkaldskontrol sender en lokalnummer som opkalds-id, skal du sørge for også at indstille parameteren Maksimal ukendt lokalnummerlængde i afsnittet Opkaldsrouting mellem og lokaler for at sikre, at upstream-opkald fra den lokale opkaldskontrol til kan klassificeres korrekt som lokale opkald. -
Tillad opkald via lokalnummer mellem lokationer: Skift til enable/disable lokalnummeropkald mellem lokationer. Denne indstilling bør kun aktiveres, hvis alle udvidelser i organisationen er unikke. Hvis indstillingen er deaktiveret, skal virksomhedens signifikante numre (styringskode, lokationskode, lokalnummer) eller telefonnumre ringes op mellem lokationer.
De første tre parametre bruges primært til at opbygge en opkaldsplan for telefoner for at minimere timeouts mellem cifre, når der opkaldes med røret af. Afvigelser fra disse globale indstillinger er stadig mulige (eksempel - lokalnumre med en anden længde kan provisioneres), men der vises en advarselsmeddelelse i Control Hub, og opkald fra telefoner kræver muligvis blokeret opkald for at undgå konflikter inden for den forudindlæste opkaldsplan.
Tabellen Eksempel på virksomhedsnummerering viser et eksempel på tre lokationer, hvor lokalnummerintervallerne for to lokationer, NYC og RTP, er identiske. Etablering af et virksomhedsnummersystem med et styringsciffer mellem lokationer 8efterfulgt af en trecifret lokationskode og det firecifrede lokalnummer skaber en ikke-overlappende forkortet opkaldsrutine mellem lokationer.
| Websted | Udvidelsesområde | Webstedskode | Enterprise-serien |
|---|---|---|---|
| NYC | 2XXX | 202 | 8 202 2XXX |
| SFO | 3XXX | 203 | 8 203 3XXX |
| RTP | 2XXX | 204 | 8 204 2XXX |
For at muliggøre en gnidningsløs overgang, bør brugernes opkaldsvaner før og efter overgangen til ideelt set være de samme. For at forberede overgangen for hver lokation skal DID-intervallerne og lokalnumre (eller forkortede opkaldsvaner inden for stedet) dokumenteres. Baseret på disse oplysninger skal det intersite styreciffer vælges.
Tabellen Forlængelseområder med fast længde viser et eksempel på tre placeringer og forlængelsesområder med fast længde. Da overlappende opkaldsvaner skal undgås, er det vigtigt at sikre, at det første ciffer i området for ethvert lokalnummerinterval ikke stemmer overens med styringscifferet for forkortet opkald mellem steder. Hvis for eksempel 8 er valgt som styreciffer for opkald mellem lokationer, kan intet lokalnummerområde på noget lokationsområde starte med 8. Typisk matcher lokalnumrene på en given placering de sidste par cifre i de DID'er, der er tildelt den pågældende placering. For at undgå konflikter kan det første ciffer i lokalnummeret ændres. Hvis for eksempel DID'er i +1 Hvis 408 555 8XXX-området bruges på en lokation, kan 7XXX i stedet for at bruge 8XXX som lokalnummerområde bruges til lokalnummerne på det pågældende sted.
| Websted | Udvidelsesområde | Lokalnumre | Webstedskode | Enterprise-serien |
|---|---|---|---|---|
| NYC | 2XXX | 2XXX | 202 | 8 202 2XXX |
| SFO | 8XXX | 7XXX | 203 | 8 203 7XXX |
| RTP | 1XX | 11XX | 204 | 8 204 11XX |
Syvcifrede opkaldsstrenge, der ringes op på en enhed ved hjælp af den amerikanske opkaldsplan, overlapper med et syvcifret mønster til lokal opkald i den forudindlæste amerikanske opkaldsplan. For at undgå overlapninger mellem opkaldsvaner online og off-net (PSTN) kan en obligatorisk ekstern adgangskode bruges på den pågældende lokation. Hvis det eksisterende virksomhedsnummerskema og det tilsvarende forkortede opkald mellem lokationer overlapper med mønstre i det nationale opkald, kan nummerskemaet under overgangen til nummerskemaet også ændres til en længere eller kortere form for at undgå overlap. Den nemmeste måde at opnå dette på er at tilføje et ekstra udfyldningsciffer til nummereringsskemaet. Det nye længere opkaldsskema mellem steder skal kun implementeres af brugere, der allerede er migreret til . Brugere, der stadig er på, kan fortsætte med at ringe syv cifre. Virksomhedens opkaldsplan skal i dette tilfælde sørge for, at forkortet syvcifret opkald fra Unified CM transformeres til enten +E.164 eller til det forkortede opkaldsformat, der er implementeret på . Dette skal gøres, før opkaldet sendes til den lokale gateway.
Tabellen Overgang til syvcifret opkald viser et eksempel på denne omnummerering. I dette eksempel bruger forkortet inter-site opkald styrecifferet 8 efterfulgt af en tocifret sitekode og et firecifret lokalnummer. For at undgå syvcifrede forkortede opkald mellem lokationer på , kan lokationskoderne nemt ændres til tre cifre ved at tilføje et vilkårligt udfyldningsciffer (8 i eksemplet) til de tocifrede lokationskoder, der bruges i , således at opkald mellem lokationer fra telefoner bruger styrecifferet 8 efterfulgt af udfyldningscifferet 8, den gamle tocifrede lokationskode og det firecifrede lokalnummer. Brugere på behøver ikke at huske nye lokationskoder; de skal kun huske at bruge 88 som præfiks til opkald mellem lokationer i stedet for 8 på .
| Websted | Lokalnumre | Webstedets kode | Enterprise-serien | Webstedsode | Enterprise ange |
| 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 |
I et scenarie med forskellige virksomhedsnummerformater aktiveret, og hvis virksomhedsnumre præsenteres som oplysninger om den opkaldende part for opkald fra til (for eksempel opkald fra enheder uden et DID), er det vigtigt også at implementere en kortlægning mellem de forskellige nummerformater for oplysninger om den opkaldende part for at sikre, at tilbagekald fungerer. Denne kortlægning kan opnås ved at bruge et transformationsmønster for den kaldende part på trunk'en mellem og den lokale gateway.
Optagelse
En veludviklet løsning til optagelse af opkald kræver omhyggelig overvejelse af flere centrale designelementer for at sikre, at den er i overensstemmelse med organisationens mål, lovgivningsmæssige krav og tekniske begrænsninger. To af de mest kritiske beslutninger involverer valg af udbyder og valg af region, som begge muligvis skal skræddersys globalt og tilsidesættes på specifikke steder baseret på forretningsbehov.
1. Valg af udbyder af opkaldsoptagelse
Det er afgørende at vælge den rette udbyder af opkaldsoptagelse for at nå forretningsmål og sikre funktionstilpasning på tværs af organisationen:
-
Valg af global udbyder: Organisationer udpeger typisk en primær udbyder af opkaldsoptagelse på globalt niveau, hvilket sikrer ensartethed i funktionssæt, overholdelse af regler og support på tværs af alle lokationer.
-
Lokationsbaserede tilsidesættelser: I scenarier, hvor specifikke lokationer eller regioner har unikke forretningsbehov eller lovgivningsmæssige krav, kan det være nødvendigt at tilsidesætte det globale udbydervalg og angive alternative udbydere for disse lokationer. Denne fleksibilitet understøtter varierende compliance-mandater og lokale driftsbehov
-
Forretningskrav: Valget af udbyder bør baseres på en vurdering af forretningsmæssige faktorer såsom overholdelse af lovgivningen (eksempel - MiFID II, HIPAA), kvalitetssikring, tvistbilæggelse eller træningsbehov.
-
Funktionstilgængelighed: Udbydere bør evalueres ud fra deres evne til at levere nødvendige funktioner, såsom overvågning i realtid, søge- og afspilningsfunktioner, kryptering, opbevaringspolitikker, integration med analyseplatforme og understøttelse af forskellige opkaldstyper (indgående, udgående, interne).
2. Valg af region
Det er afgørende for overholdelse af regler og ydeevne at bestemme det område, hvor opkaldsoptagelser gemmes og behandles:
-
Valg af global region: Som standard kan organisationer vælge en enkelt region til lagring af opkaldsoptagelser for at forenkle administration og styring.
-
Lokationsbaserede områdetilsidesættelser: Hvor love om dataopbevaring eller virksomhedspolitikker kræver det, kan det være nødvendigt at tilsidesætte den globale regionsindstilling for bestemte steder og sikre, at opkaldsoptagelser gemmes og behandles inden for de krævede geografiske grænser.
-
Krav til dataopbevaring: Designet skal tage højde for internationale og lokale databeskyttelsesregler (såsom GDPR, CCPA eller landespecifikke påbud), som kan diktere, hvor og hvordan opkaldsoptagelser opbevares.
Et andet vigtigt aspekt, der skal tages højde for under planlægning og design af en løsning til optagelse af opkald, er estimering af lagerbehov. Det er vigtigt at forudsige lagerbehovene præcist for at sikre, at der er tilstrækkelig kapacitet til rådighed til at understøtte den løbende forretningsdrift, opretholde overholdelse af regler og undgå afbrydelser.
Flere nøgleparametre bør overvejes ved fastlæggelse af det forventede lagerbehov:
-
Antal optagede opkald: Vurder det forventede antal opkald, der vil blive optaget inden for et givet tidsinterval (f.eks. pr. dag, uge eller måned). Dette omfatter ikke kun eksterne opkald, men også intern kommunikation, hvis det kræves af forretningspolitik eller lovgivningsmæssige påbud.
-
Gennemsnitlig opkaldsvarighed: Beregn den typiske længde af optagede opkald, da længere opkald vil optage mere lagerplads. Variationer i opkaldsvarighed på tværs af forskellige afdelinger eller brugergrupper bør også tages i betragtning i estimatet.
-
Opbevaringsperiode: Definer, hvor længe optagelser skal opbevares, hvilket ofte dikteres af organisationens politikker eller eksterne regler (såsom branchespecifikke compliance-standarder). Længere opbevaringsperioder vil øge de samlede opbevaringskrav
-
Vækstprognoser: Overvej forventet vækst i opkaldsvolumen eller udvidelse af optagelsesomfanget, hvilket kan skyldes forretningsskalering, nye lovgivningsmæssige krav eller onboarding af yderligere brugere eller lokationer.
Ved grundigt at analysere disse parametre kan organisationer udvikle en robust lagringsstrategi, der sikrer skalerbarhed, omkostningseffektivitet og overholdelse af lovgivningen for deres opkaldsoptagelsesløsning. Det er også tilrådeligt regelmæssigt at gennemgå og justere lagerallokeringer, efterhånden som brugsmønstrene udvikler sig over tid.
Nødopkald
Kravet om at dirigere et nødopkald til det relevante alarmcenter er et krav for enhver opkaldstjeneste, der tilbyder PSTN-tjeneste. Med er routing af nødopkald indbygget i løsningen og inkluderer understøttelse af alle nationale nødnumre i de lande, der understøtter . Routningen af et nødopkald er baseret på den definerede placering og placeringens PSTN-adgangsmetode. Nødnumrene er foruddefinerede og specifikke for det land, hvor brugerne og enhederne er installeret.
Der er to metoder til at foretage nødopkald. Der er en grundlæggende nødopkaldsrutetjeneste og en udvidet nødopkaldsrutetjeneste. Den grundlæggende nødopkaldsrutetjeneste bruger et administratorvalgt nummer til at identificere placeringen og opkaldsruten for at nå nødtjenesterne. Ved basale nødopkald går opkaldsstien typisk via kundens PSTN-mulighed for den pågældende lokation. har også forbedret nødopkaldsrouting designet til implementeringer i USA og Canada, der har lovgivningsmæssige krav, der kræver brug af en landsdækkende udbyder til at levere nødopkald til det korrekte alarmcenter.
Alle kunder bør som minimum implementere den grundlæggende nødopkaldskonfiguration. Grundlæggende nødopkald kræver, at mindst én kunde ejet +E.164 nummer tildeles hver placering defineret i . Ved basale nødopkald vil hver placering være defineret af en gadeadresse, som politi, brandvæsen eller ambulancetjenester sendes til i tilfælde af nødsituationer. I de fleste tilfælde er hovednummeret for lokationen det bedste valg til at repræsentere den fysiske placering af nødsituationen. Typisk er tildelingen af adressen til +E.164 Nummeret er koordineret med PSTN-udbyderen. Billederne nedenfor viser tildelingen af det hovednummer, der skal bruges som nødopkaldsnummer for Richardson-lokationen.
I de fleste tilfælde er en bygningsadresse tilstrækkelig som afsendelsesadresse for lokationen. Men hvis der er behov for yderligere placeringsoplysninger for bestemte brugere eller enheder, kan en administrator bruge den samme proces som beskrevet ovenfor og tildele disse enheder til en bestemt adresse eller en mere præcis placering inden for adressen (f.eks. en etage eller et rum). I Brugeradministration i , giver fanen Opkald mulighed for at bruge et specifikt nummer til en bruger og deres enheder for at få en specifik afsendelsesadresse. De følgende billeder illustrerer, hvordan et specifikt nummer kan tildeles en enhed. Administratoren er ansvarlig for at sikre, at det nummer, der bruges af enheden, har fået tildelt den korrekte afsendelsesadresse. Adressetildelingen udføres typisk via PSTN-udbyderen på den pågældende lokation.
For amerikansk-baserede telefoniinstallationer, der skal tilbyde forbedrede nødopkaldsløsninger, anvendes RedSkys Horizon Mobility integreret i routing af nødopkald. Når RedSky bruges til opkaldsrouting, skal en administrator tilmelde sig en konto via Cisco og konfigurere de relevante oplysninger i Opkald -> Tjenesteindstillinger for at aktivere denne funktion. Når RedSky-tjenesten er blevet aktiveret på systemniveau, vil en administrator aktivere RedSky-tjenesten på hvert lokationsniveau. Aktivering af Udvidede Nødopkald på en Lokation vil aktivere tjenesten for alle enheder, der er tildelt den pågældende lokation. Enheder, der understøtter forbedrede nødopkald, er Cisco MPP-telefoner, Cisco PhoneOS-telefoner og Ciscos .
Der er to indstillinger til at aktivere udvidede nødopkald på en lokation. Funktionen Tillad RedSky at modtage netværksforbindelsesoplysninger og testkald skal bruges til at bekræfte, at RedSky-konfigurationen for enheds- og infrastrukturtilknytninger er korrekt. Denne indstilling tillader også testopkald til 933 for at udføre placeringsverifikation ved hjælp af RedSkys IVR-system til at aflæse den opkaldendes placering. Selvom dette dokument ikke dækker RedSky-konfigurationen til positionssporing, bør en administrator ALTID teste sin positionsregistrering, før nødopkald aktiveres for at dirigere til RedSky. Når testen er afsluttet og verificeret som nøjagtig, vil administratoren dirigere opkald til RedSky ved at slå nødopkald til/fra RedSky til/fra. Denne knap vil omdirigere alle nødopkald fra lokationen til RedSky til levering til lokationens telefonsvarercentral.
Indstillingerne for udvidede nødopkald gælder også for klienter både lokalt og eksternt. Når de er lokalt, kan de spores på samme måde som bordtelefoner spores. Når brugeren er uden for lokaler, vil vedkommende kunne indstille sin placering dynamisk direkte i . For mere information om nødopkald, se Udvidede nødopkald til
Licensering
Der er flere muligheder for at tildele licenser til brugere.
Manuel tildeling via
Administratorer tildeler manuelt licenser til individuelle brugere via brugergrænsefladen.
Administratorer kan redigere servicelicenser for individuelle brugere og tildele opkaldslicenser direkte.
Automatiske licenstildelingsskabeloner
Brug skabeloner til licenstildeling til automatisk at tildele licenser til brugere baseret på gruppe- eller organisationsindstillinger.
Automatisk licensering kan udføres via katalogsynkronisering eller manuelle brugeropdateringer, men brugerne skal have et gyldigt +E.164 formateret telefonnummer, og telefonnumrene skal findes på en placering før brugerprovisionering. Hvis betingelserne ikke er opfyldt (f.eks. ugyldigt telefonnummerformat), vil licenser ikke blive tildelt.
Massetildeling via CSV-skabelon
Upload en CSV-fil med brugeroplysninger og licenstildelinger for at tilføje eller ændre flere brugere på én gang.
CSV-import understøtter tilføjelse af op til 20.000 brugere og tildeling af licenser, men licenser kræver specifikke felter som telefonnummer og lokalnummer.
API-baseret tildeling
Brug API'er til programmatisk at tildele licenser og administrere brugere.
understøtter API-operationer til bruger- og licensadministration (People, SCIM 2.0 og Licenses API'er), som kan udnyttes til automatisering af licenstildeling. Licenses API'en tillader samtidig tildeling af licenser, telefonnumre og lokalnumre.
| Tildelingsmetode | Fordele | Ulemper |
|---|---|---|
| Manuel gennem | Simpelt for få brugere. Giver præcis og detaljeret kontrol over licenstildeling. | Ikke skalerbar, tidskrævende Udsat for menneskelige fejl under manuel indtastning. |
| Automatiske licensskabeloner | Skalerbar Reducerer manuelle fejl Kan anvendes på nye og eksisterende brugere. | Kræver gyldige telefonnumre og placeringer. Mere kompleks at sætte op Kræver også brugergrupper pr. brugergruppe med tilsvarende licenskrav. |
| Masseupload af CSV | Effektiv til store brugergrupper Tillader samtidig tildeling af licenser, telefonnumre og lokalnumre. | Kræver omhyggelig CSV-formatering Potentiale for fejl, hvis telefonnumre eller lokalnumre mangler eller er forkerte. |
| API-baseret tildeling | Automatiserbar, fleksibel. Tillader samtidig tildeling af licenser, telefonnumre og lokalnumre. | Kræver udvikling og API-kendskab. |
Tabellen Brugerklargøringsmuligheder - oversigt opsummerer brugerklargøringsmulighederne og deres fordele og ulemper. Denne oversigt hjælper med at vælge den bedste metode til licenstildeling baseret på kundens organisationsstørrelse, automatiseringsmuligheder og brugerprovisioneringsprocesser og -krav.
Hvor det er muligt, anbefaler Cisco at tildele opkaldslicenser ved hjælp af licensskabeloner. Dette kræver, at der for hver gruppe af brugere, der kræver et unikt sæt licenser (eksempel - Standard vs. Professionel), findes en gruppe med de respektive gruppemedlemskaber. Som beskrevet i afsnittene Brugergrupper kan brugergrupper defineres manuelt i eller synkroniseres fra en virksomhedsmappe. En kombination af begge tilgange er mulig.
Brugere, der tilhører flere grupper, får licenser fra alle tildelinger, der gælder for alle deres grupper. Dette gør det muligt at bruge licensspecifikke sikkerhedsgrupper i virksomhedskataloget til at administrere licenstildeling, hvor den resulterende brugerlicenstildeling styres af foreningen af gruppemedlemskaber.
For mere information, se Opsæt automatiske licenstildelinger i Control Hub og Opsæt automatiske licenstildelingsskabeloner for Webex Calling-brugere.
Licenskrav
Dette afsnit dækker kun relaterede licenser. Andre licenstyper (eksempel - Webex-enhedsregistrering, beskeder, møder) er ikke dækket. Som en del af designprocessen skal licenskravene fastlægges. Licensantallet for følgende licenstyper skal beregnes:
-
Standard: antal individuelle brugere, der kræver standardtelefonifunktioner.
-
Professionel: antal brugere og arbejdsområder, der kræver avancerede telefonifunktioner. Virtuelle linjer og gruppe-voicemail har ret til en 1:1 forholdet for hver professionel licens. I sjældne tilfælde, hvor antallet af nødvendige virtuelle linjer eller gruppe-voicemails overstiger antallet af brugere og arbejdsområder, der kræver avancerede telefonifunktioner, skal der derfor tages højde for yderligere professionelle licenser.
-
Arbejdsområde til fællesområde: antal steder med delt brug eller fællesområder, der kræver standardopkaldsfunktioner.
-
Kundehjælp: antal agenter og supervisorer, der kræver Customer Assist-funktioner. Kundesupporten inkluderer den professionelle licens.
-
Rutelisteopkald: antal nødvendige Cloud Connected PSTN-opkald mellem lokale brugere and/or lokale specialiserede tredjepartsapplikationer.
-
Attendant-konsol: antal brugere, der kræver adgang til Attendant Console-klienten.
-
Cisco-opkaldsabonnement (udgående opkaldsabonnement): antal brugere, der har brug for et PSTN-nummer and/or Adgang til udgående PSTN-opkald for Cisco PSTN-tjenesten.
Der er ingen dedikeret licenstype til professionelle arbejdsområder. Professionelle arbejdsområder bruger en professionel licens.
Arbejdsområder kun med hotdesk tilbyder hotdesking-værtstjenesten og nødopkald fra hotdesking-værten og kræver ingen licens. For yderligere information, se Tilføj og administrer enheder kun til hot desk.
For at bestemme den nødvendige licenstype for hver bruger og arbejdsområde baseret på de nødvendige funktioner, se Funktioner tilgængelige efter licenstype for Webex Calling.
For at skelne mellem funktionalitet, der tilbydes af opkaldskøer kombineret med den professionelle licens i modsætning til kundeassistance, se Webex Calling opkaldskø og kundeassistancefunktionssammenligning.
Brugerklargøring
Når du klargør brugere i Webex, er der flere muligheder tilgængelige, som hver især er egnet til forskellige organisatoriske behov og miljøer:
-
Manuel klargøring: Administratorer kan tilføje og administrere individuelle brugere direkte i . Denne metode er ligetil, men bedst egnet til små organisationer eller begrænsede brugerændringer.
-
Masselevering via CSV: For større brugerbaser kan administratorer importere og opdatere brugere på én gang ved at uploade CSV-filer til . Dette muliggør effektiv administration af op til tusindvis af brugere på én gang.
- Indstillinger for katalogsynkronisering:
Katalogforbindelse: Dette er et automatisk synkroniseringsværktøj, der bruges i Microsoft Active Directory-miljøer. Den synkroniserer brugerkonti, grupper og attributter planlagt (hver time, dagligt eller ugentligt). Den understøtter Active Directory-opsætninger med flere domæner og flere skove og kan synkronisere profilbilleder og rumobjekter.
Guideapp til Entra ID (Azure AD): Denne metode er designet til organisationer, der bruger Microsoft Entra ID (Azure AD), og den giver automatisk synkronisering af brugerkonti og attributter i næsten realtid direkte fra Entra ID til . Det administreres fuldt ud internt og kræver minimal opsætning.
SCIM 2.0-applikationer: For ikke-Microsoft-miljøer eller andre identitetsudbydere som Okta eller Duo muliggør SCIM-baserede synkroniseringsapps automatisk brugerklargøring og -deklarering med attributtilknytning og gruppesynkronisering.
-
Synkronisering af Unified CM-brugere: Denne indstilling giver mulighed for at oprette brugerkonti baseret på eksisterende slutbrugere ved at synkronisere fra til . Dette kræver, at Cloud Connected UC (CCUC) kører på de lokale klynger. Det anbefales dog generelt at synkronisere brugere fra en centraliseret cloud-mappe som Entra ID i stedet for direkte fra .
-
API-klargøring: Offentlige API'er (People, SCIM 2.0) kan bruges til at provisionere brugere. Den største fordel ved at bruge API'er er muligheden for at integrere brugerprovisionering med andre virksomhedssystemer.
Denne oversigt og tabel afspejler de vigtigste muligheder for brugerklargøring, deres fordele og begrænsninger for at hjælpe dig med at vælge den bedste tilgang til din organisations behov.Tabel 6. Brugerklargøringsmuligheder for Provisioneringsmetode Beskrivelse Fordele Ulemper Manuel Create/manage brugere individuelt i Enkel for få brugere; ingen infrastruktur nødvendig Ikke skalerbar; tidskrævende for mange brugere Masse (CSV-fil) Import/update brugere samlet via CSV i Effektiv til grupper; ingen kodning nødvendig Manuel CSV-forberedelse; mindre dynamisk Mennesker og SCIM 2.0 API Programmatisk brugeradministration via Webex API'er Fleksibel; understøtter automatisering og integration Kræver udvikling og infrastruktur Adressebogssynkronisering Automatisk synkronisering fra AD, Entra ID, SCIM-apps, Unified CM Automatiserer livscyklus; understøtter filtrering og kortlægning Opsætningskompleksitet: Nogle af mulighederne har begrænsede funktioner eller kræver infrastruktur
Brugergrupper
Brugergruppestyring giver administratorer mulighed for at organisere brugere i grupper for effektiv massestyring af licenser, indstillinger og ressourcer. Grupper hjælper med at strømline administrationen ved at anvende politikker, licenser og indstillingsskabeloner på flere brugere samtidigt i stedet for at administrere brugerne individuelt.
Administration af brugergrupper tilbyder adskillige fordele, herunder:
-
Forenklet administration: Administrer licenser, indstillinger og politikker for flere brugere på én gang.
-
Konsistens: Anvend ensartede indstillinger og licenser på tværs af brugere i den samme gruppe.
-
Skalerbarhed: Understøtter op til 250.000 medlemmer pr. gruppe.
-
Integration: Synkroniser grupper fra Microsoft Entra ID (Azure AD) eller Active Directory for automatiseret bruger- og gruppeadministration.
-
Fleksibilitet: Opret lokale grupper eller synkroniser sikkerhedsgrupper; administrer gruppemedlemskab manuelt eller via CSV-filer.
-
Ressourceallokering: Styr adgang til integrerede apps og tjenester baseret på gruppemedlemskab.
De primære anvendelsesscenarier for brugergrupper ved provisionering er:
-
Licenstildelinger: Tildel licenser til grupper for automatisk at levere tjenester som opkald, møder, beskeder eller hybridtjenester til gruppemedlemmer.
-
Indstillingsskabeloner: Anvend samlinger af tjenesteindstillinger (f.eks. beskeder, møder, opkald) på grupper for at opnå ensartet brugeroplevelse.
-
Massebrugeradministration: Tilføj eller fjern brugere på én gang via CSV-filer eller mappesynkronisering.
-
Automatisering og integration: Brug API'er eller mappesynkronisering til automatiseret administration af bruger- og gruppelivcyklus.
Følgende tabel opsummerer de forskellige muligheder for at administrere brugergrupper og gruppeadministration i .
| Valgmulighed | Beskrivelse | Fordele | Ulemper |
|---|---|---|---|
| gruppeklargøring (grupper) | Opret og administrer grupper direkte i . Add/remove medlemmer manuelt eller via CSV. | Fuld kontrol over gruppemedlemskab Øjeblikkelig anvendelse af licenser og skabeloner Nemt at oprette og redigere grupper |
Manuelle opdateringer kræves Risiko for fejl ved manuelle CSV-uploads Ingen automatisk synkronisering med eksterne mapper |
| Synkroniserede grupper fra Entra ID (Azure AD) eller Active Directory | Synkroniser automatisk sikkerhedsgrupper og medlemskaber fra eksterne katalogtjenester. | Automatiseret synkronisering reducerer manuelt arbejde Sikrer overensstemmelse med virksomhedens register Støtter store organisationer |
Kan ikke redigere gruppemedlemskab i Synkroniseringsforsinkelse på op til 12 timer Indlejrede grupper kræver manuel valg |
| Grupper og SCIM 2.0 API (Grupper) | Brug Grupper eller SCIM 2.0 API til programmatisk gruppe- og medlemskabsadministration | Automatisering og integration med andre systemer Skalerbar til store eller komplekse miljøer |
Kræver udviklingsindsats Kompleksitet afhænger af API-brug |
Selvom synkroniserede grupper sikrer konsistens og tilbyder et enkelt administrationspunkt, er en hybrid tilgang, der kombinerer synkroniserede grupper og grupper (enten administreret i kontrolhub eller via API'er), mulig. Så for eksempel kan grupper til licenstildeling være synkroniserede grupper, og et separat sæt grupper kan bruges til at tildele bruger- og kaldskabeloner.
Denne omfattende tilgang til administration af brugergrupper gør det muligt for organisationer effektivt at administrere brugerlicenser, indstillinger og politikker, hvilket sikrer ensartede og skalerbare samarbejdsoplevelser.
Anbefalet fremgangsmåde ved migrering fra til
Den primære datakilde for brugere er databasen, som indeholder slutbrugeroplysninger. er dog typisk ikke den autoritative kilde til brugeridentitetsstyring, og endnu vigtigere vil den blive lukket ned ved overgangens afslutning og er derfor udelukket som en langsigtet autoritativ kilde til identitetsoplysninger.
Cisco anbefaler at bruge en centraliseret cloud-mappe, f.eks. Microsoft Entra ID (Azure AD), som den eneste sandhedskilde for brugeridentiteter. Synkronisering af brugere fra Entra ID sikrer konsistens, forenkler administration og understøtter single sign-on (SSO)-funktioner.
For at sikre at alle brugere også er til stede i Entra ID, bør organisationer verificere, at brugerkontiene svarer til konti i Entra ID. Dette kan gøres ved at eksportere brugerlister fra og sammenligne dem med Entra ID-brugerlister.
Kort sagt er den anbefalede klargøringsmetode at synkronisere brugere fra Microsoft Entra ID (Azure AD) til Webex ved hjælp af Azure AD-guiden eller SCIM-apps. Manuel og CSV-bulkprovisionering er tilgængelige som supplerende metoder, men er mindre skalerbare og mere fejlbehæftede for store organisationer. Det er afgørende for en vellykket migrering og en ensartet brugeroplevelse på tværs af alle miljøer at sikre, at Entra ID er den autoritative kilde, og at alle brugere findes i Entra ID.
Overgang fra en lokal katalogtjeneste, som Active Directory, til en cloud-katalogtjeneste, som Entra ID (Azure ID), er uafhængig af den kaldende overgang. Cisco anbefaler at afslutte overgangen til en cloud-katalogtjeneste, før overgangen til opkald påbegyndes.
Design af brugergrupper
Efter overførsel af virksomhedskataloget fra det lokale miljø til skyen skal du indsamle de nødvendige brugergrupper baseret på licens- og funktionsskabelonkrav. For hvert gruppedokument:
-
Gruppenavn: gruppens unikke navn.
-
Licenser: licenser, der skal tildeles denne gruppe (hvis nogen) og omfang (skal licenser tildeles eksisterende brugere eller kun nye brugere)
-
Indstillingsskabeloner: Webex-app og skabeloner til brugeropkald.
-
Katalogsynkronisering: Vil denne gruppe blive synkroniseret fra virksomhedskataloget, eller er dette en lokal Webex-gruppe, der er klargjort i Control Hub eller via en API.
-
Beskrivelse: Hvordan vil denne gruppe blive brugt, og hvilke brugere skal være medlemmer af gruppen
Disse oplysninger vil blive brugt senere i implementeringsfasen til at oprette lokale grupper eller grupper i virksomhedskataloget og administrere brugernes gruppemedlemskab.
Enkeltlogon (SSO)
Cisco anbefaler brugen af SSO til brugergodkendelse. Brug af SSO har nogle overbevisende fordele, herunder:
-
Forenklet brugergodkendelse: Brugere kan logge ind én gang med deres virksomhedsoplysninger (f.eks. fra Azure ID) for at få adgang til andre integrerede applikationer, hvilket eliminerer behovet for flere adgangskoder og reducerer antallet af login-prompter. Dette forbedrer sikkerheden ved at sikre, at virksomhedsadgangskoder aldrig gemmes eller overføres efter godkendelse.
-
Forenklet brugeradministration: Automatiserer oprettelse, opdateringer og deaktivering af brugerkonti baseret på ændringer i virksomhedens katalog, hvilket reducerer administrative omkostninger og sikrer, at kun autoriserede brugere har adgang.
-
Forbedret sikkerhed: SSO reducerer adgangskodetræthed og risikoen for adgangskoderelaterede brud ved at centralisere godkendelse gennem betroede identitetsudbydere (IdP'er).
-
Nem integration af multifaktorgodkendelse (MFA): MFA kan nemt understøttes enten via en Identity Access Management-løsning som Cisco Duo eller via MFA-understøttelse af IdP'en.
Der er flere muligheder for at implementere SSO for tjenester:
-
SAML 2.0-baseret SSO: Den primære protokol, der understøttes til SSO-integration, og som muliggør sikker udveksling af godkendelsesoplysninger mellem IdP'en og tjenesteudbyderen.
-
OpenID-forbindelse (OIDC): Understøttes som en alternativ moderne godkendelsesprotokol til SSO-integration.
-
Webex-identitet: Understøttes også som en identitetsudbydermulighed.
SSO konfigureres og administreres centralt via , hvilket kræver udveksling af metadata mellem og den valgte IdP.
Efter konfiguration kan SSO testes inden aktivering for at sikre korrekt opsætning.
Cisco understøtter integration med flere testede og almindeligt anvendte IdP'er og identitetsstyringssystemer (IAM), herunder, men ikke begrænset til:
-
Cisco Duo
-
Okta
-
Microsoft Active Directory Federation Services (ADFS)
-
Microsoft Azure
-
PingFederate
-
OpenAM
-
F5 STOR-IP.
Disse IdP'er overholder SAML 2.0- eller OpenID Connect-standarderne og er blevet valideret for kompatibilitet med Ciscos samarbejdsløsninger.
Understøttelse af flere IdP'er
giver organisationer mulighed for at konfigurere SSO med flere IdP'er for at imødekomme komplekse IT-miljøer såsom fusioner, opkøb eller decentraliserede IT-afdelinger, hvor forskellige grupper bruger forskellige IdP'er. Understøttelse af flere IdP'er kan enten implementeres ved hjælp af funktionen til flere IdP'er i eller gennem integration af et virksomheds-IAM-system som Cisco Duo.
's understøttelse af flere identitetsudbydere (IdP'er) adresserer adskillige vigtige anvendelsesscenarier, hvor organisationer kræver fleksibel og sikker godkendelse på tværs af forskellige IT-miljøer:
1. Fusioner og anskaffelser
Når virksomheder fusionerer eller opkøber andre, har de ofte separate IT-infrastrukturer og forskellige IdP'er, der ikke kan fødereres. Understøttelse af flere IdP'er giver brugere fra begge organisationer mulighed for at autentificere og samarbejde sikkert uden at skulle forene deres identitetssystemer med det samme.
2. Flere uafhængige IT-afdelinger
Store organisationer eller offentlige institutioner kan have flere uafhængige IT-afdelinger, der hver administrerer deres egen IdP. 's funktion til flere IdP'er gør det muligt for disse afdelinger at vedligeholde deres egne godkendelsessystemer, samtidig med at brugerne får problemfri adgang.
3. Forskellige brugergrupper eller domæner
Organisationer med forskellige brugergrupper (f.eks. medarbejdere vs. leverandører) eller flere e-maildomæner kan konfigurere routingregler til at dirigere godkendelsesanmodninger til den relevante IdP baseret på domæne- eller gruppemedlemskab. Dette understøtter differentierede adgangspolitikker og sikkerhedskontroller.
4. Understøttelse af forskellige godkendelsesprotokoller
understøtter SAML- og OpenID Connect (OIDC) IdP'er, hvilket giver organisationer mulighed for at integrere forskellige typer identitetsudbydere i henhold til deres eksisterende infrastruktur og sikkerhedskrav.
5. Forbedret sikkerhed og overholdelse af regler
Ved at aktivere flere IdP'er kan organisationer implementere stærkere godkendelsesmekanismer, herunder multifaktorgodkendelse (MFA) gennem integrationer som Duo, og håndhæve ensartede sikkerhedspolitikker på tværs af forskellige brugerbaser.
6. Forenklet brugeroplevelse
Brugere kan godkende ved hjælp af deres eksisterende legitimationsoplysninger fra deres respektive IdP'er, hvilket giver en samlet loginoplevelse på trods af den underliggende kompleksitet af flere identitetssystemer.
Selvom understøttelse af flere IdP'er giver fleksibilitet, kræver det omhyggelig koordinering mellem sikkerheds- og identitetsteams for at opretholde ensartede sikkerhedspolitikker og undgå potentielle sårbarheder.
Duo MFA med SSO til
Duo Access Gateway (DAG) kan godkende brugere ved hjælp af eksisterende lokale eller cloudbaserede mapper såsom Active Directory (AD) og OpenLDAP. Det understøtter også integration med andre identitetsudbydere som Microsoft ADFS, Microsoft Azure, Okta, OneLogin, CAS og Shibboleth. Denne fleksibilitet giver organisationer mulighed for at bruge deres nuværende kataloginfrastruktur til Webex SSO med Duo MFA.
Duo fungerer som et stærkt godkendelseslag oven på godkendelsen af den primære mappe. Den fungerer som en identitetsudbyder (IdP), der bruger SAML 2.0 til at håndhæve tofaktorgodkendelse (2FA), før der gives adgang til . Duo evaluerer bruger-, enheds- og netværkskontekst i forhold til konfigurerbare politikker for at tillade eller nægte adgang, hvilket forbedrer sikkerheden ud over blot brugernavn og adgangskode. Duo tilbyder også fleksible politikkontroller, såsom at kræve MFA ved hvert login for nogle apps og sjældnere for andre.
Fordelene ved Cisco Duo inkluderer:
-
Forbedret sikkerhed: Tilføjer phishing-resistent MFA for at beskytte adgang og reducere risikoen fra kompromitterede adgangskoder.
-
Fleksible politikker: Giver detaljeret kontrol over godkendelseskrav pr. applikation eller brugergruppe.
-
Integration med eksisterende mapper: Understøtter lokal AD, OpenLDAP, cloud-kataloger og forskellige SSO-udbydere, hvilket minimerer ændringer i infrastrukturen.
-
Brugervenlighed: Understøtter Single Sign-On (SSO) for at reducere træthed med adgangskoder ved at give brugerne mulighed for at logge ind én gang og få sikker adgang til flere ressourcer.
-
Pålidelige slutpunkter: Understøtter enhedstillid for klienter på Windows og macOS, hvilket forbedrer sikkerhedstilstanden.
-
Selvbetjeningstilmelding: Indlejret tilmelding og duo-prompt forbedrer brugeroplevelsen under MFA-opsætning.
Duo MFA med SSO udnytter eksisterende mapper som Active Directory og OpenLDAP eller cloudidentitetsudbydere til at godkende brugere. Duos rolle er at levere en stærk, politikdrevet anden godkendelsesfaktor integreret via SAML 2.0, hvilket forbedrer sikkerheden og samtidig opretholder brugervenlighed via SSO. Fordelene omfatter forbedret sikkerhedstilstand, fleksibel håndhævelse af politikker, problemfri integration og en bedre brugeroplevelse.
Cisco anbefaler implementering af SSO for brugere. For forbedret sikkerhed anbefales integration med Cisco Duo.
Enterprise IAM- og SSO-strategien bør implementeres, før overgangen fra til . påbegyndes.
Funktioner
har et komplet udvalg af kernefunktioner, der er inkluderet i tjenesten. Dette inkluderer mange opkaldsfunktioner i virksomhedsklassen, der har været tilgængelige i mange år. Du ser muligvis ikke 100 % lighed mellem funktioner og funktioner, men som du kan se i nedenstående figur, er de vigtigste opkaldsfunktioner tilgængelige i .
Udover de mange brugerfunktioner har platformen også kernesystemfunktioner, der er inkluderet i platformen. Disse omfatter funktioner som automatiske omstillinger, opkaldskøer, opkaldsparkering osv. Du kan se alle de tilgængelige kernefunktioner i systemet under Service → Opkald → Funktioner som vist i figur Webex Calling-kernefunktioner.
Automatisk omstilling
Den automatiske assistent giver mulighed for 24/7 automatisering af håndtering af indgående opkald, hvilket muliggør effektiv opkaldshåndtering uden behov for at en person besvarer hvert opkald.
Den automatiske omstillingsfunktion besvarer indgående opkald og giver den, der ringer op, en menu med muligheder for, hvor de vil dirigere deres opkald hen. Dette kan være til en person, en telefonsvarer eller en opkaldstjeneste (f.eks. opkaldskø). Den, der ringer op, bruger telefonens tastatur til at indtaste nummeret fra den automatiske omstillingsmenu.
Den automatiske assistent understøtter følgende nøglefunktioner:
-
Forretnings- og eftertidstider
-
Ferieplan
-
Opkaldsmenufunktion til at dirigere dine kunder til det sted, de skal hen
-
Tilpas hilsner
-
Opkald efter navn-mulighed
-
Indstillinger for viderestilling af opkald
-
Control Hub-analyser og -rapporter.
For yderligere information, se Administrer automatiske ombud.
Parkering af opkald
Opkaldsparkering giver brugerne mulighed for nemt at sætte et opkald på hold, så en anden bruger nemt kan hente det, når de er tilgængelige til at tage det. Det frigør også den bruger, der besvarede det oprindelige opkald, til at foretage eller modtage andre opkald, mens opkaldet er parkeret.
Der er to typer opkaldsparkeringer tilgængelige i :
-
Direkte opkaldsparkering - giver enhver bruger mulighed for at parkere et opkald til en anden brugers lokalnummer eller til et lokalnummer for opkaldsparkering, som defineret af administratoren.
-
Opkaldsparkeringsgruppe - giver en defineret gruppe brugere mulighed for automatisk at parkere opkald mod tilgængelige parkeringsdestinationer, der er defineret for gruppen. Disse destinationer kan være gruppemedlemmernes lokalnumre eller parkerede opkaldsloknumre.
Baseret på konfigurationen og parkeringstypen kan brugerne hente opkald ved at ringe til *88+><extension of parked call>, trykke på linjetasten, der er knyttet til lokalnummeret for parkeret opkald, eller bruge en programtast på deres IP-telefon.
Der er en mulighed for at kalde et parkeret opkald tilbage efter en bestemt periode til den bruger, der parkerede opkaldet, eller til en alternativ bruger.
Du kan finde flere oplysninger i Administrer opkaldsparkering i Control Hub.
Opkaldsbesvarelse
Opkaldsbesvarelse giver en administrator mulighed for at definere en gruppe brugere (medlemmer), der kan besvare et opkald til et andet medlems telefon. Dette giver en bruger mulighed for at besvare opkald, når deres holdkammerater er optaget og ikke kan besvare et indgående opkald.
Brugerne i en gruppe skal være på samme placering.
Brugere kan bruge enten eller deres bordtelefon til at besvare et opkald.
-
:
-
Understøtter visuelle og lydnotifikationer
-
Notifikation om indgående opkald
-
FAC-baseret (opkald *98) eller notifikations-toast-opkaldsbesvarelse
-
Notifikationer om besvarelse af opkald for flere linjer.
-
-
Bordtelefoner:
-
Notifikation om indgående opkald
-
Lydsignaler og visuel notifikation via håndsættets LED-indikator. 6821 understøtter kun lydklokker
-
Når den valgte notifikationstype i ikke er ingen
-
-
Kun notifikationer om besvarelse af opkald for primære linjer.
-
For yderligere information, se Konfigurer opkaldsmodtagelsesgruppe
Opkaldskø
inkluderer kun stemmebaserede opkaldskøer som en del af dens kernefunktioner, og enhver bruger med en professionel licens kan være en del af en opkaldskø, agent eller supervisor. Denne funktion giver brugerne mulighed for effektivt at interagere med kunder. Opkaldskøer understøtter en delmængde af nogle af callcenterets kernefunktioner, såsom talekøer, tilbagekald, færdigheds- eller prioritetsrouting, administration af agentkøer, analyser, rapportering osv.
Ciscos opfordring til Microsoft Teams-integration giver agenter adgang til opkald og funktioner i opkaldskøen direkte fra deres Microsoft Teams-klient.
Opkaldskøer understøtter følgende nøglefunktioner:
-
Hilsener og beskeder (velkomst, trøst, hvisken osv.)
-
Hold musik
-
Tilbagekald
-
Politikker for køruting (natkørsel, helligdage, videresendelse)
-
Agentkø login/logout
-
Administration af agentkøstatus
-
eller bordtelefonsupport
-
Supervisor-agent opkaldsovervågning, coaching, indbrud eller overtagelse via funktionsadgangskoder (FAC'er)
-
(administratoradgang) til:
-
køhåndtering
-
Analyse og rapportering af agenter og køer
-
Kø-, agent- og supervisorstyring.
-
For yderligere information, se Konfigurer opkaldskø.
har en tilføjelsesfunktion til Customer Assist, der giver yderligere muligheder i opkaldskøen og giver agenter og supervisorer en bedre brugeroplevelse i . For en sammenligning af funktionerne Opkaldskø og Kundehjælp, se Webex Calling opkaldskø og kundehjælpsfunktionssammenligning.
Søgegruppe
Søgegrupper giver mulighed for at dirigere indgående opkald til en bestemt gruppe brugere via et forudbestemt opkaldsrutemønster. Dette sikrer, at opkald besvares af den rette gruppe brugere eller sendes til en telefonsvarer til opfølgning.
En stor forskel mellem søgegrupper og opkaldskøer er, at opkald ikke sættes i kø i en søgegruppe, så hvis der ikke er nogen brugere i søgegruppen tilgængelige til at besvare opkaldet, vil det blive afbrudt, sendt til telefonsvarer eller viderestillet til et andet nummer (bruger eller tjeneste).
Du kan finde flere oplysninger i Administrer søgegrupper i Control Hub.
Driftstilstande
Funktionen Driftstilstande giver virksomheder mulighed for effektivt at dirigere opkald til forskellige destinationer (brugere, telefonsvarer, opkaldstjenester som f.eks. en opkaldskø). Hvor og hvornår et opkald dirigeres hen, er baseret på en tidsplan for både døgnet og ugedagen, og enhver bruger kan autoriseres til at administrere disse tilstande (planer) for at kontrollere ændringer i opkaldsroutningen.
Som et eksempel kan opkald til en opkaldskø dirigeres til en anden opkaldskø med agenter i en anden tidszone for at besvare opkald efter lukketid, i åbningstiden dirigeres til de lokale agenter, og i helligdage dirigeres til telefonsvarer for opfølgning, når agenter vender tilbage til kontoret.
En autoriseret bruger kan skifte mellem disse forskellige viderestillingsscenarier (tilstande), hvis de har brug for at ændre, hvor indgående opkald dirigeres hen i en bestemt periode. Disse brugere kan administrere tilstandene via deres 6800/7800/8800 MPP-telefoner, 9800-telefoner eller i brugerhubben på Administrer tilstande.
For mere information, se Opkaldsrouting baseret på driftstilstande i Webex Calling.
Paging-gruppe
Personsøgergrupper giver brugerne mulighed for at foretage et envejsopkald for at sende en lydbesked til en gruppe af brugere. Hver gruppe kan indeholde op til 75 målbrugere and/or arbejdsområder, der nås ved at ringe til et foruddefineret nummer eller lokalnummer.
Når en bruger ringer til en personsøgergruppe, foretages der et samtidigt opkald til alle de tildelte mål i gruppen, hvorefter den, der ringer op, kan indtale sine beskeder og lægge på, når de er færdige.
Du kan finde flere oplysninger i Konfigurer en personsøgergruppe i Control Hub.
Optagelser
understøtter optagelse af opkald foretaget eller modtaget af en bruger. Dette kan være påkrævet af hensyn til kvalitet, sikring, sikkerhed eller træning. Som standard optages opkald i , men andre tredjepartsudbydere af optagelser kan også bruges, hvis andre optagelsesfunktioner eller overholdelse af og lovgivningsmæssige krav er påkrævet.
Når den bruges som optageplatform, administreres alle optagede opkald i . Fuldstændige administratorer med rollen som complianceansvarlig kan afspille og downloade optagelserne. Uden rollen som compliance officer kan administratoren kun slette optagelserne.
For mere information om denne funktion og en liste over tredjepartsoptagelser, se Administrer opkaldsoptagelse for Webex Calling.
Single Number Reach
Rækkevidde med et enkelt nummer gør det muligt for opkald til en brugers telefonnummer at ringe til flere enheder. Dette kan omfatte andre bordtelefoner såvel som mobiltelefoner. Opkald kan også foretages fra disse enheder, og brugerne kan pushe og pull-opkald mellem dem.
Du kan finde flere oplysninger om denne funktion og hvordan en administrator konfigurerer den i Konfigurer kontakt med enkeltnummer (kontor hvor som helst).
For mere information om, hvordan en bruger kan administrere og konfigurere denne funktion for sig selv i Webex-brugerhub (portal), se Konfigurer rækkevidde med et enkelt nummer (kontor hvor som helst).
Telefonsvarergruppe
Voicemail-grupper giver mulighed for en delt voicemail-boks, der kan tildeles en bruger eller en opkaldsroutingfunktion. Nogle af grundene til, at en voicemail-gruppe kan være nødvendig, er:
-
Generel voicemail til en afdeling eller arbejdsgruppe
-
Tilføj telefonsvarerbesked til en automatisk omstilling eller søgegruppe
-
Sådan sender du overløbsopkald fra en opkaldskø
-
Brugere, der kun har brug for en telefonsvarer.
For mere information, se Administrer en delt voicemail og indgående faxboks til Webex Calling.
Attendant Console er angivet på siden Opkaldsfunktioner i Webex, men det er en tilføjelsesfunktion, der kræver køb af Attendant Console-licensen for at kunne bruges.
For yderligere information, se Kom godt i gang med Attendant Console.
For information om alle funktioner, inklusive nogle tilføjelsesfunktioner, se Funktioner tilgængelige efter licenstype for Webex Calling.
Implementer
Netværksberedskab
Det første skridt i overgangen til er at sikre en pålidelig og sikker internetforbindelse mellem det lokale netværk og skyen.
Da de fleste organisationer opretter forbindelse til internettet via en eller flere firewalls eller sikkerhedsenheder, er det vigtigt at validere, at de nødvendige trafikstrømme understøttes.
Netværks- og sikkerhedsadministratorer skal forstå disse flows med hensyn til:
-
Retning (indgående vs. udgående)
-
Protokoller (Eksempel - SIP TLS, SRTP, HTTPS)
-
IP-adresseintervaller brugt af tjenester
-
Portnumre der skal åbnes eller tillades.
Dette sikrer, at virksomhedens firewalls, NAT-enheder og anden netværksinfrastruktur er korrekt konfigureret til at håndtere trafik, samtidig med at virksomhedens sikkerhedspolitikker opretholdes.
For information om de nødvendige flows, herunder IP-adresse, porte og protokoller, se Portreferenceoplysninger for Webex Calling. Brug disse oplysninger til at konfigurere firewallen, proxyer og anden netværksinfrastruktur i den eksisterende installation for at aktivere netværksflows.
Decentraliseret internetopdeling fra hver filial eller lokation er den anbefalede tilgang til cloud-samarbejdstjenester som f.eks. Ved at tillade trafik at forlade lokalt, gør denne model følgende:
-
Reducerer forsinkelser og jitter frem og tilbage, hvilket forbedrer den samlede opkaldskvalitet
-
Skalerer effektivt efterhånden som flere brugere og websteder overgår til
-
Fungerer problemfrit med SD-WAN, som dynamisk kan dirigere sessioner til det nærmeste cloud-indgangspunkt for optimal ydeevne
- Giver mulighed for at spore brugerplacering baseret på deres offentlige IP-adresse, hvilket hjælper med analyse af mediestier og fejlfinding.
Derudover skal organisationer sikre tilstrækkelig internetbåndbredde på hvert sted. Båndbredden bør dimensioneres baseret på det forventede antal samtidige opkald, den valgte codec (f.eks. Opus eller G.711) plus overhead til signalering, retransmissioner og vækst. Dette stemmer overens med forberedelsesfasen i PPDIO-livscyklussen og etablerer et solidt fundament for migrering.
Indledende opsætning
Det indledende opsætningsafsnit i implementeringsfasen af udrulningen er grundlæggende for at etablere et velstruktureret og håndterbart cloud-opkaldsmiljø. Denne fase omfatter kritiske opgaver såsom opsætning af organisationen, anskaffelse og tildeling af licenser samt verificering og krav på din virksomheds domæner for at sikre korrekt brugeradministration og sikkerhed. Derudover omfatter det klargøring af licensskabeloner for at automatisere tildeling af brugerlicenser, konfiguration af Single Sign-On (SSO) for at strømline brugergodkendelse og forbedre sikkerheden samt justering af tjeneste- og klientindstillinger, så de stemmer overens med organisationens politikker og brugerbehov. Fuldførelsen af disse indledende opsætningsaktiviteter sikrer, at miljøet er korrekt konfigureret til skalerbarhed, sikkerhed og en problemfri brugeroplevelse, hvilket lægger grunden for efterfølgende implementerings- og driftsfaser.
Domænebekræftelse
For at kunne identificere brugere, der er registreret med din virksomheds e-maildomæner på , er det vigtigt at verificere dine domæner. Uden domænebekræftelse vil brugerne blive tildelt en forbrugerorganisation, hvilket komplicerer brugeradministrationen for din virksomhed. Domænebekræftelse er et obligatorisk trin, der giver din organisation mulighed for at gøre krav på og administrere disse brugere effektivt.
Sørg for, at alle domæner, der er knyttet til dine brugeres e-mailadresser, er verificeret. Domæneverifikation er ikke eksklusiv; det samme domæne kan verificeres på tværs af flere organisationer.
For mere information om administration af domæner, se Administrer dine domæner.
Gør krav på (konverter) eksisterende brugere
Når du har bekræftet dine domæner, kan du fortsætte med at gøre krav på brugere, der har registreret sig til at bruge din virksomheds e-maildomæner, i din organisation. Denne proces konsoliderer alle brugere under én organisatorisk paraply, hvilket muliggør centraliseret styring og strømlinet administration. Ved at gøre krav på disse brugere sikrer du, at din virksomhed har fuld kontrol over brugerkonti, så du kan tildele passende licenser, konfigurere tjenester og yde den nødvendige support effektivt. Denne samlede administrationstilgang forbedrer sikkerheden, forenkler brugerklargøring og sikrer ensartet adgang til tjenester på tværs af din organisation. At gøre krav på brugere forhindrer også, at de administreres i eksterne organisationer eller forbrugerorganisationer, hvorved organisationens integritet og kontrol over samarbejdsressourcer opretholdes.
For mere information om at gøre krav på brugere, se Gør krav på brugere til din organisation (konverter) brugere.
Konfigurer og test katalogsynkronisering
For at muliggøre problemfri bruger- og gruppeadministration kan du synkronisere brugere og grupper fra din virksomhedsmappe enten Microsoft Entra ID (tidligere Azure AD) eller Microsoft Active Directory (AD) til . Denne proces sikrer, at brugeridentiteter og gruppemedlemskaber vedligeholdes konsekvent på tværs af dit miljø.
For organisationer, der implementerer fasede implementeringer, er det afgørende at kontrollere og begrænse omfanget af synkronisering under de indledende udrulninger. Dette minimerer risikoen for utilsigtede ændringer og muliggør målrettet testning før bredere implementering.
Den mest effektive metode til at filtrere, hvilke brugere der synkroniseres, er at udnytte medlemskab af kataloggrupper:
| 1 |
Opret en dedikeret synkroniseringsgruppe: I din virksomhedsmappe (Microsoft Entra ID eller AD) skal du oprette en sikkerhedsgruppe specifikt til synkronisering (f.eks. synkroniseringsgruppe). |
| 2 |
Udfyld gruppen med målbrugere: Tilføj kun de brugere, du vil synkronisere (f.eks. en testgruppe i pilotfasen), til denne gruppe. Dette giver dig mulighed for at kontrollere præcist, hvem der er inkluderet i synkroniseringsprocessen. |
| 3 |
Konfigurer synkroniseringsaftalen med gruppebaseret filtrering: Når du konfigurerer synkroniseringsaftalen i Directory Connector eller Entra ID-klargøring, skal du konfigurere omfanget til kun at omfatte brugere, der er medlemmer af den angivne gruppe.
|
| 4 |
Udvid gruppen efter behov: Efterhånden som du går videre til bredere implementeringsfaser, skal du blot tilføje yderligere brugere eller grupper til synkroniseringsgruppen. Synkroniseringsområdet udvides automatisk til at omfatte disse brugere, hvilket muliggør en kontrolleret og gradvis udrulning. Eksempel på implementeringstrin:
Referencer: Synkroniser Entra ID-brugere i Control Hub |
Opsæt og test Single Sign-On (SSO)
Single Sign-On (SSO) forbedrer sikkerheden og forenkler brugeradgang ved at give brugerne mulighed for at godkende én gang med deres virksomhedslegitimationsoplysninger og få problemfri adgang til . understøtter SSO-integration med SAML 2.0-kompatible IdP'er, herunder Microsoft Entra ID (tidligere Azure AD), Active Directory (AD) fødererede løsninger og forskellige tredjeparts IdP'er.
På dette tidspunkt bør den designede SSO-opsætning implementeres og testes.
Referencer:
Single sign-on-integration i kontrolhub
Konfigurer enkeltlogon til WebEx-administration
Indkøb, levering og verificering af licenser
Som en del af den indledende opsætning er det vigtigt at anskaffe, klargøre og verificere de relevante licenser for at aktivere og administrere tjenester effektivt. Indkøbsprocessen involverer valg af licenstyper baseret på brugerroller og arbejdsbelastninger, såsom Professional-, Standard- og Workspace-licenser. Licenser genereres og leveres via Ciscos softwareplatforme eller gennem partnere. Efter anskaffelse og klargøring skal det korrekte antal licenser verificeres i . Denne proces sikrer, at organisationen har de korrekte licenser aktiveret og klar til brug i implementeringen.
Som en del af den indledende licensopsætning i [mangler kontekst] er det vigtigt at konfigurere organisationsbaseret automatisk licensering for at strømline licenstildeling for nye brugere. Denne opsætning gør det muligt at tildele licenser automatisk, når brugere tilføjes til organisationen, hvilket eliminerer behovet for manuel licenstildeling. Når du konfigurerer automatisk licensering på organisationsniveau, vælger du de tjenester, der skal tildeles, og definerer omfanget, f.eks. at anvende licenser kun på fremtidige brugere eller også inkludere eksisterende brugere.
Hvis din implementeringsplan i stedet involverer brug af automatisk licensering på gruppeniveau, kan du vælge ikke at tildele licenser på organisationsniveau for at undgå konflikter eller dubletter af licenstildelinger. Med automatisk licensering på gruppeniveau tildeles licenser baseret på gruppemedlemskab. Brugere i flere grupper modtager licenser fra alle relevante gruppetildelinger.
Gruppebaseret konfiguration af licenstildeling skal udføres, når katalogsynkroniseringen er fuldført, så der findes synkroniserede grupper, som kan bruges til licenstildeling.
Specifikt kræver automatisk licenstildeling yderligere klargøringsoplysninger, såsom brugerplacering og tildeling af telefonnummer. Brugerens arbejdstelefonnummer skal være i +E.164 format, forudklareret og tildelt en gyldig placering, for at licensen kan aktiveres automatisk. Hvis disse betingelser ikke er opfyldt, vil brugeren ikke blive tildelt tjenester automatisk og kan kræve manuel indgriben.
Kort sagt, konfigurer organisationsbaseret automatisk licensering for nye brugere, hvis du ønsker en bred, organisationsomspændende licenstildeling. Hvis du foretrækker mere detaljeret kontrol eller har forskellige licensbehov pr. gruppe, skal du konfigurere automatisk licensering på gruppeniveau og undgå at tildele licenser på organisationsniveau for at forhindre overlapning og sikre korrekt licensadministration.
Indstillinger for Webex Calling-tjenesten
Det er vigtigt at foretage en omfattende gennemgang og konfiguration af de globale serviceindstillinger i .
Start med at gå til og navigere til indstillingssektionen. Undersøg omhyggeligt hver konfigurerbar indstilling, herunder, men ikke begrænset til, intern opkaldskonfiguration, parametre for nødopkald, politikker for opkaldsrouting, administration af telefonsvarer og enhedens standardindstillinger.
Juster disse globale indstillinger, så de afspejler din organisations politikker og designbeslutninger.
Også opsætningsindstillinger og bruger- og app-skabeloner.
Pilotmigrering
I implementeringsfasen repræsenterer udførelsen af en pilotmigrering en kritisk milepæl i valideringen af overgangen fra til . Dette pilotprojekt involverer etablering af en repræsentativ delmængde af brugere på tværs af en eller flere lokationer på platformen, hvilket sikrer, at den valgte population afspejler forskellige use cases og organisatoriske roller. Parallelt med brugermigrering skal vigtige samarbejdstjenester, herunder telefonsvarer, automatiske omstillinger, opkaldskøer og søgegrupper, overføres til deres tilsvarende tjenester for at opretholde forretningskontinuitet og servicefunktionalitet.
Pilotmigreringen bør udnytte den samme kombination af Cisco-leverede værktøjer og tredjepartsmigreringsværktøjer, der er planlagt til den bredere organisatoriske implementering, hvilket sikrer, at processerne, automatiseringsarbejdsgangene og integrationspunkterne valideres grundigt under repræsentative forhold.
De primære mål med denne pilotimplementering er todelte: for det første at validere og forfine de samlede overgangsprocesser, herunder brugerprovisioneringsworkflows, datamigreringsprocedurer og endpointkonfigurationer; og for det andet at omfattende verificere funktionaliteten af migrerede tjenester under reelle driftsforhold.
Denne faseopdelte tilgang giver projektteamet mulighed for at identificere og afhjælpe eventuelle tekniske eller proceduremæssige problemer i et kontrolleret miljø, indsamle brugerfeedback om den nye platformoplevelse, vurdere effektiviteten af udvalgte migreringsværktøjer og etablere tillid til migreringsmetoden, før der fortsættes med en bredere organisatorisk implementering.
Den indsigt, der opnås i løbet af denne pilotfase, er afgørende for at optimere efterfølgende migreringsbølger og sikre en gnidningsløs og risikobegrænset overgang for hele virksomheden.
Anskaf PSTN
For at anskaffe PSTN-tjenester til skal du først vælge en PSTN-forbindelsesmulighed i .
Hvis en organisation planlægger at opretholde hybrid dobbelt opkaldskontrol ( fase 1 i figur Faseopdelt opkaldsovergang: Hybrid og Cloud) enten midlertidigt eller på ubestemt tid, skal de implementere en eller flere lokale gateways til lokale PSTN'er for at tillade opkald mellem og slutpunkter.
Hvis en fuld overgang ( fase 2) til skyen er det endelige mål, inklusive PSTN, kræves enten en Cisco-opkaldsaftale eller en Cloud Connect-mulighed for PSTN.
Arbejd sammen med din valgte udbyder for at bestille og portere telefonnumre, før du konfigurerer dem i . Det er kun muligt at bestille telefonnumre eller iværksætte portordrer. required/possible til lokal PSTN og Cloud Connect til . For Cisco-opkaldsabonnementer initieres bestilling og portering fra Control Hub, så snart placeringen er oprettet, og i lande, hvor Cisco-opkaldsabonnementet er tilgængeligt. Du kan finde flere oplysninger om Cisco Calling-abonnementer i Introduktion til Cisco-abonnementerne.
Som en del af PSTN-implementeringen skal du sørge for, at din udbyder har aktiveret både indgående og udgående PSTN-tjenester for din placering. Udfør desuden testopkald for at kontrollere, at opkald dirigeres korrekt via din valgte PSTN-forbindelse.
Konfigurer placeringer
Før du tilføjer brugere og enheder til , skal du klargøre opkaldssteder. For hver lokation skal der indtastes en gyldig gadeadresse. I USA og Canada valideres og bruges denne adresse af platformen til at sende PIDF-LO-lokationsoplysninger til nødopkald.
Når du konfigurerer lokationer, der bruger lokalt PSTN, skal du konfigurere de lokale gateways i overensstemmelse hermed. I skal der oprettes en trunk og en rutegruppe for hver lokal gateway, og rutegruppen tildeles derefter som PSTN-valg for lokationen. Cisco anbefaler kraftigt altid at vælge en rutegruppe som PSTN-valg, da denne tilgang giver dig mulighed for nemt at tilføje yderligere trunks i fremtiden, hvilket understøtter både skalerbarhed og redundans. Cisco anbefaler også at aktivere dobbelt identitet og P-Charge-Info-understøttelse på alle PSTN-trunker, da dette forenkler identifikationen af den fakturerbare part for udgående direkte eller viderestillede opkald. Hvis din PSTN-udbyder bruger en anden faktureringsheader, kan du kopiere oplysningerne fra P-Charge-Info-headeren på den lokale gateway til den nødvendige faktureringsheader.
For placeringer, der bruger Cloud Connect eller Cisco-opkaldsabonnementet som deres PSTN-mulighed, skal du blot vælge det respektive PSTN-valg for placeringen under opsætningen. Hvis lokationen bruger enten Cloud Connect til eller lokalt PSTN, skal du tilføje de telefonnumre, der blev bestilt i det forrige trin. Numre kan tilføjes som inaktive, hvis du ikke ønsker, at de skal inkluderes i opkaldsrouting med det samme. Du kan aktivere disse numre senere, når de er tildelt brugere eller funktioner.
Det er vigtigt altid at indstille hovednummeret for hver lokation. Hovednummeret kan tildeles enten en bruger eller en funktion, f.eks. en automatisk omstilling. For at aktivere voicemail på placeringen skal du sørge for at indstille voicemail-pilotnummeret, også kendt som stemmeportalnummeret.
Yderligere indstillinger for opkaldssteder omfatter konfiguration af nødopkaldsoplysninger såsom nødnummeret til tilbagekald, notifikationsmuligheder og forbedrede nødopkaldsfunktioner. Du bør også gennemgå og justere optagelsesindstillinger, sprogpræferencer og enhedskonfigurationer efter behov for hver lokation. Hvis din organisation bruger forkortede interne opkald på nettet med virksomhedens signifikante numre, skal du huske at konfigurere en unik lokationskode for lokationen i de interne opkaldsindstillinger. Endelig, hvis eksternt opkald kræver et udgående opkaldsciffer, skal du sørge for at indstille dette i indstillingerne for eksternt opkald. Når et udgående opkaldsciffer er konfigureret, anbefaler Cisco at aktivere håndhævelse af udgående opkaldsciffer for at sikre ensartethed.
Integration med lokal opkaldsstyring
For at integrere med lokal opkaldskontrol er det nødvendigt at konfigurere trunks, rutegrupper, virksomhedens opkaldsplaner og både lokations- og globale indstillinger. Start med at konfigurere trunks og lokale gateways, der er beregnet til sammenkobling med det lokale opkaldsstyringssystem. Dette trin er kun nødvendigt, hvis der er behov for dedikerede trunks. Hvis eksisterende trunks og rutegrupper er tilstrækkelige til din implementering, kan de genbruges til den lokale forbindelse uden yderligere konfiguration.
Når trunks og rutegrupper er etableret, skal du fortsætte med at oprette virksomhedens opkaldsplaner og tildele den relevante rutegruppe som destination for hver opkaldsplan. Når integration involverer flere lokale opkaldsstyringssystemer forbundet via forskellige trunker, vil der være behov for flere opkaldsplaner. Det er vigtigt at sikre, at disse opkaldsplaner kun indeholder de mønstre, der er nødvendige for at dirigere opkald til lokale destinationer.
Hvis din implementering kræver understøttelse af ukendt udvidelsesrouting, skal denne funktion aktiveres på lokationsniveau. Derudover skal du, når ukendt lokalnummerrouting er aktiveret, angive den maksimale ukendte lokalnummerlængde i afsnittet Opkaldsrouting mellem og lokaler i indstillingerne for opkaldstjenester i . Dette sikrer problemfri opkaldsrouting og korrekt håndtering af lokalnummerbaserede opkaldsscenarier i dit integrerede miljø.
Migrer brugere i batches
Når du migrerer brugere fra til, kan du muligvis ikke flytte alle brugere på samme tid. Dette kan skyldes flere årsager, herunder, men ikke begrænset til, antallet af websteder eller brugere, hvor lang tid det tager at overføre et websted and/or gruppe af brugere på én gang, begrænsede IT- eller webstedsressourcer til at understøtte ændringsvinduet, varigheden af ændringsvinduet, ændringens kompleksitet osv.
Når du migrerer brugere i faser, er det afgørende at identificere, hvilke brugere der skal migreres sammen i den samme batch. Det primære mål er at migrere brugere, der er afhængige af hinanden i forhold til deres opkaldstjenester og -funktioner, sammen. Du vil sikre dig, at alle deres opkaldsfunktioner (eksempel - opkaldskøer) er fuldt funktionelle, ligesom de var før overgangen.
Selv hvis du implementerer opkaldsinterworking mellem og med lokale gateways, kan du ikke opdele delte tjenester eller funktioner på tværs af denne forbindelse. Derfor skal du identificere afhængighederne mellem brugerne ved at se på funktioner som:
-
Overvågning af andre brugere ved hjælp af BLF'er
-
I den samme jagtpilot, opkaldskø osv.
-
delt linje
-
Brug af opkaldsbesvarelse
-
Brug af de samme parkerede opkaldsnumre
-
Samtaleanlæg
-
Executive/Admin.
Et eksempel ville være en bruger, der er en del af en Hunt-gruppe, der overgår til . Denne bruger vil overgå til Hunt-gruppen og til alle andre medlemmer af Hunt-gruppen. Derfor kan Hunt Group og dens medlemmer efter overgangen besvare opkald på den nye platform.
Dette bliver mere udfordrende, når brugerne er forbundet til forskellige grupper af brugere for forskellige opkaldstjenester og -funktioner. Dette vil kræve overførsel af mere end én gruppe brugere og én opkaldstjeneste til på samme tid.
Brug outputtet fra Migration Insights-værktøjet eller et tredjepartsværktøj, som du brugte i forberedelsesfasen til at bestemme, hvilke brugere og funktioner der skal grupperes sammen. Dette output burde have været brugt til at udvikle din migreringsplan og vil give dig indsigt i, hvordan du vil gruppere brugere og funktioner, der skal overgå, sammen.
De vigtigste trin ved overgang af en gruppe brugere er:
-
Identificering af brugere, der skal migreres sammen
-
Bekræft, at alle brugere er inde
-
Bekræft, at alle TN'er for brugerne findes i
-
Bekræft korrekt telefonnummerformat i telefonbogen
-
Sørg for, at licens- og indstillingsskabelonen for brugergrupperne er konfigureret korrekt.
-
Bekræftelse eller konfiguration af alle opkaldstjenester og -funktioner for brugergruppen (før eller under overgangen, alt efter hvad der er relevant)
-
Tilføj brugere til gruppen af opkaldsaktiverede brugere i virksomhedens telefonbog
-
Udnytt værktøjer - værktøjer til bruger- og funktionsmigrering and/or tredjepartsværktøjer
-
Disable/Delete user/device telefonnummer og opkald features/services efter overgangen.
Efter migrering af en gruppe brugere skal du teste en delmængde af brugerne for at validere, at alle deres opkaldsfunktioner og -tjenester fungerer korrekt. Hvis opkaldsfunktioner som f.eks. opkaldskø, søgegrupper osv. overgår til brugergruppen, skal du teste disse opkaldstjenester for korrekt funktionalitet.
Arbejdsområder
I refererer et arbejdsområde til en delt placering (som et konferencerum, et mødested eller en hot desk), der kan tildeles enheder, lokalnumre og brugere. I modsætning til traditionelle Unifed CM-telefoner er arbejdsområder:
-
Lokationscentreret: knyttet til fysiske rum.
-
Enhedsfleksibel: kan have en eller flere enheder (bordtelefoner, tavler osv.).
Når arbejdsområder er blevet identificeret som en del af overgangen til , kan de tilføjes under Enheder. Hvert arbejdsområde skal tildeles en enhed, og hvis de allerede er i Unified CM, skal de nulstilles eller klargøres igen. Funktioner som telefonsvarer, viderestilling af opkald og besvarelse af opkald kan aktiveres eller deaktiveres, og politikker kan anvendes til videoopkald, opkaldsparkering og mobilitet efter behov. Test hvert arbejdsområde ved at foretage interne og eksterne opkald, og test video-, konference- og mobilitetsfunktioner. Til sidst, giv brugerne besked om eventuelle gældende processer for arbejdspladsenheder og bookinger.
For mere information om arbejdsområder i , se Arbejdsområder.
Klargøring af enheder
Telefoner, der i øjeblikket er registreret til , skal migreres til som en del af cloud-overgangen. For at gøre migreringen så enkel som muligt med minimal risiko for fejl anbefaler Cisco at migrere fysiske lokationer eller afdelinger på samme tid. Du kan dog blive nødt til at migrere brugere i batches på grund af funktionsafhængigheder. Se afsnittet Migrer brugere i batches for yderligere oplysninger.
Alle understøttede telefoner, som du skal skifte fra, skal konfigureres som en bruger eller et arbejdsområde, og den fysiske telefon skal omkonfigureres for at blive registreret hos . Derudover skal firmwaren på telefoner i 7800- og 8800-serien opgraderes fra Enterprise-firmware til Multiplatform Phone (MPP)-firmware. Denne proces omfatter indlæsning af overgangsfirmware før indlæsning af den MPP-firmware, der kræves til registrering. Det kræver også den relevante migrationstilladelse. Cisco har forbedret denne proces i løbet af de seneste par år for at gøre det nemmere for dig at opgradere dine Enterprise-telefoner til MPP-firmware. Du kan finde flere oplysninger om trinnene til at fuldføre firmwareopgraderingen i Konverter Cisco 7800- og 8800-seriens IP-telefoner mellem Enterprise- og MPP-firmware.
Ud over de trin, der er beskrevet i denne artikel, er der et indbygget værktøj, Migrer din telefon til Webex Calling, som du kan bruge til at migrere dine 7800- og 8800-telefoner fra Enterprise- til MPP-firmware. Dette værktøj giver dig også mulighed for at tilføje telefonerne til og tildele dem til de relevante brugere eller arbejdsområder. For mere information om brug af værktøjer, se Migrer din telefon.
For telefoner i 9800-serien, der er registreret med ovenstående krav om firmwaremigrering, gælder det ikke. Disse telefoner kører PhoneOS, som understøttes af både og . For at overføre disse telefoner skal du tilføje dem til Webex Calling, tildele dem til en bruger eller et arbejdsområde og derefter nulstille telefonerne til fabriksindstillingerne. PhoneOS-opstartssekvens til registrering Figuren nedenfor viser PhoneOS-opstartssekvensen og hvordan telefonen registreres, når den er blevet tilføjet til , selvom telefonen stadig er aktiveret. and/or DHCP-indstillinger (eksempel - 150) er i brug.
understøtter fabriksnulstilling af PhoneOS-enheder for at muliggøre Zero-Touch onboarding til. administratorer kan eksternt nulstille fabriksindstillingerne for 9800- og 8875-telefonerne via CUCM-administrationssiderne, hvilket eliminerer behovet for fysisk adgang til telefonerne for at onboarde telefonerne til. Denne funktion understøttes med enhedspakkerne fra 9. september 2025:
-
CUCM v15 - Unified Communications Manager version 15
-
CUCM v14 - Unified Communications Manager version 14.
For yderligere information om registreringsprocessen for 9800-serien, se Registreringsproces.
Ud over Cisco IP-telefonerne kan det være nødvendigt at klargøre andre enheder, såsom analoge telefonadaptere (ATA'er), trådløse telefoner (WiFi, DECT), videoenheder, stemmegateways og enheder og telefoner fratredjeparter . Mange af disse enheder har ikke en firmwareopgraderingssti som IP-telefoner til at overføre dem fra virksomhedsfirmware til cloud-firmware. Derfor skal du klargøre hver af disse enheder i Control Hub. Nogle af disse kan ikke overføres til, og den tilsvarende model skal erstatte den (f.eks. ATA 191/192) og andre vil kræve manuel omkonfiguration and/or softwareændringer.
- Stemmegateways - For at migrere din lokale gateway, se Migrer lokal gateway.
Du kan finde flere oplysninger om konfiguration af din stemmegateway VG400, VG410 eller VG420 i Control Hub under Lokal gateway
-
Analog telefonadapter (ATA) - For at komme i gang med din Cisco ATA 191 og 192, se Cisco ATA.
-
Trådløs Wifi-telefon - For at integrere trådløs telefon 840 og 860, se Integrer Webex trådløs telefon.
-
DECT trådløse telefoner - For at komme i gang med din nye Cisco IP DECT 6800-serie, se Cisco IP DECT.
For at opbygge og administrere et digitalt DECT-netværk i Control Hub, se Administrer DECT-netværk
For mere information om Cisco IP DECT 6800, se Implementeringsvejledning
-
3. partsenheder og -telefoner - Arbejd med 3. partsleverandører på device/phone krav og processen til at migrere eller erstatte dem for at understøtte .
Konfigurer funktioner
Alle nødvendige opkaldsfunktioner skal klargøres før eller under overgangen. Som beskrevet i afsnittet Migrer brugere i batches, skal opkaldsfunktionerne konfigureres og overføres, når de brugere, der bruger dem, overføres.
Du kan finde oplysninger om, hvordan du konfigurerer hver af funktionerne, i de tilsvarende konfigurationshjælpeartikler.
-
Automatiske ombud - For at administrere automatiske ombud, se Automatiske ombud
-
Opkaldsparkering - For at administrere opkaldsparkering, se Opkaldsparkering
-
Opkaldsmodtagelse - For at konfigurere opkaldsmodtagelsesgruppen, se Opkaldsmodtagelse
-
Opkaldskøer - For at konfigurere opkaldskø, se Opkaldskø
-
Jagtgrupper - For at administrere jagtgrupper, se Administrer jagtgruppe
-
Driftstilstande - For opkaldsrouting baseret på driftstilstande, se Opkaldsrouting baseret på driftstilstande
-
Personsøgergrupper - For at konfigurere en personsøgergruppe, se Konfigurer en personsøgergruppe
-
Optagelser - For at administrere opkaldsoptagelse for , se Administrer optagelser
-
Kontakt med enkelt nummer - For at konfigurere kontakt med enkelt nummer (kontor hvor som helst), se Konfigurer enkelt nummer
-
Voicemail-gruppe - For at administrere en delt voicemail og indgående faxboks for , se Administrer voicemail.
Accepttest
Accepttest sikrer, at det migrerede miljø opfylder de funktionelle krav, fungerer som forventet og leverer en problemfri brugeroplevelse på tværs af alle kommunikationsworkflows. Denne valideringsproces er mangesidet og dækker alt fra brugerklargøring og nummertildelinger til den operationelle ydeevne af avancerede opkaldsfunktioner.
Dette afsnit giver eksempler og fremhæver vigtige aspekter at overveje under accepttest; det er dog ikke ment som en udtømmende eller omfattende tjekliste.
Brugerklargøring og nummertildeling
Et grundlæggende aspekt af accepttest involverer at verificere, at alle brugere er provisioneret nøjagtigt og fuldstændigt inden for . Dette kræver en grundig sammenligning mellem kildemappen () og den nyetablerede brugerbase for at sikre, at alle brugerkonti, sammen med tilhørende attributter såsom lokalnumre og DID-tildelinger (Direct Inward Dial), er blevet korrekt migreret. Fuldstændig klargøring er afgørende, ikke kun for driften fra dag ét, men også for den løbende administration og support.
Validering af nummertildeling omfatter bekræftelse af, at hver bruger er tildelt det korrekte lokalnummer og eksterne nummer, og at disse numre dirigeres korrekt i både interne (on-net) og eksterne (PSTN) opkaldsstrømme. Det er vigtigt at kontrollere for eventuelle overlapninger, manglende tildelinger eller fejlkonfigurationer, der kan føre til fejl i opkaldsrouting eller afbrydelser af tjenesten.
PSTN-opkaldsflow og præsentation af nummeropkald
En robust accepttestprocedure skal omfatte end-to-end validering af PSTN-opkaldsstrømme. Dette inkluderer både indgående og udgående opkaldsscenarier. For indgående PSTN-opkald skal testteamet bekræfte, at opkald leveres til de tilsigtede slutpunkter, uanset om det er individuelle brugere, opkaldskøer, søgegrupper eller automatiske omstillinger. Udgående PSTN-opkald skal foretages korrekt, med særlig opmærksomhed på korrekt levering og præsentation af opkalds-ID-oplysninger. Dette indebærer at sikre, at det korrekte opkaldsnavn og nummer vises til eksterne modtagere i overensstemmelse med organisationens politikker og lovgivningsmæssige krav.
Testning bør også adressere failover-scenarier, såsom håndtering af utilgængelige slutpunkter eller netværksafbrydelser. Dette hjælper med at bekræfte, at fallback-mekanismer og alternativ routing fungerer korrekt, hvilket opretholder tjenestekontinuitet og pålidelighed.
Opkaldsstrømme på nettet
Interne, eller on-net, opkaldsstrømme danner rygraden i virksomhedens kommunikation. Accepttest på dette område verificerer, at opkald mellem brugere i organisationen dirigeres korrekt, med funktioner som omstilling, hold, viderestilling og konferencer, der fungerer som tilsigtet. Integriteten af opkaldsplaner, forbindelse mellem lokalnumre og understøttelse af organisationens opkaldspolitikker skal alle bekræftes.
Håndtering af brugeropkald og funktionsvalidering
Et vigtigt aspekt af accepttestning involverer validering af, hvordan brugere håndterer opkald ved hjælp af og understøttede bordtelefoner. Denne proces fokuserer på at bekræfte, at de daglige opkaldsworkflows er intuitive og pålidelige, og at brugerne har problemfri adgang til de kernefunktioner, der er nødvendige for deres roller. Testningen bør vurdere, hvor nemt brugerne kan foretage og modtage opkald, administrere funktioner til at parkere og genoptage opkald samt udføre både blinde og konsultative omstillinger. Det er også vigtigt at kontrollere, at viderestilling af opkald, konferencer og andre avancerede funktioner, såsom parkering og hentning af opkald eller aktivering af "Forstyr ikke", er let tilgængelige og fungerer problemfrit.
Oplevelsen bør evalueres med hensyn til klarhed og responstid, idet der tages højde for, hvordan brugerne interagerer med opkaldshistorik, telefonsvarer og integrerede telefonbøger. Der bør lægges ekstra vægt på muligheden for at flytte aktive opkald mellem enheder og effektivt bruge kontroller under opkald i applikationen eller på fysiske telefoner. Det endelige mål er at sikre, at slutbrugeroplevelsen er ensartet, effektiv og fuldt ud understøtter organisationens kommunikationsbehov efter migreringen.
Opkaldskøer: Erfaring med agent og supervisor
Opkaldskøer bruges ofte til at håndtere scenarier med stort antal indgående opkald. Accepttest fokuserer her på flere dimensioner. Først skal det verificeres, at opkald distribueres til agenter i henhold til den konfigurerede kølogik, f.eks. Round Robin, længste inaktiv tid eller samtidig ringning. Præsentationen af opkald i kø på agenternes skriveborde skal undersøges for klarhed og brugervenlighed, så agenterne effektivt kan acceptere, vente og viderestille opkald.
For supervisorer bør desktopoplevelsen evalueres for funktioner som overvågning i realtid, opkaldsforstyrrelser og analyser eller indsigt i køens ydeevne. Dette inkluderer, men er ikke begrænset til, validering af dashboards og rapporteringsværktøjer, der leverer handlingsrettede data om opkaldsfordeling, agentaktivitet og kømålinger.
Søgegrupper: Opkaldsfordeling
Søgegrupper er en nøglemekanisme til at distribuere opkald til foruddefinerede brugergrupper. Accepttest skal bekræfte, at opkald dirigeres til gruppemedlemmer baseret på den konfigurerede søgealgoritme, og at overløb, videresendelse og manglende svar håndteres i henhold til designet. Det er afgørende for driftsmæssig konsistens og brugertilfredshed at sikre, at gruppemedlemskab og opkaldsroutingadfærd stemmer overens med dem, der tidligere er etableret i .
Automatiske omstillinger: Meddelelser og menufunktioner
Automatiske ombud repræsenterer frontlinjen inden for automatiseret opkaldshåndtering. Testningen skal dække afspilning af meddelelser, nøjagtigheden af optagede hilsner og den korrekte funktion af menustrukturer. Menuvalg skal pålideligt dirigere opkaldere til de relevante afdelinger, personer eller eksterne numre. Testning bør også omfatte ugyldige scenarier eller timeout-scenarier for at bekræfte, at opkaldere modtager klar vejledning eller omdirigeres som tilsigtet.
Voicemail-betjening
Endelig er voicemail-funktionaliteten afgørende for brugeroplevelsen. Accepttests bør verificere, at voicemail-bokse er korrekt tildelt og tilgængelige, både internt i organisationen og eksternt. Muligheden for at optage, hente og administrere beskeder skal bekræftes, sammen med levering af notifikationer.
Optimer
PSTN-migrering til Cloud Connect for
Når alle slutpunkter og brugere er migreret til cloudopkald, er Unified CMs eneste formål at fungere som en transit mellem PSTN-gateways og via den lokale gateway. Fjernelse af PSTN-gateways og lokal gateway fra billedet ved at bruge Cloud Connect som PSTN-adgang for alle Webex Calling-brugere har flere fordele, herunder omkostningsreduktion og forbedret pålidelighed. Følg disse trin for at overføre lokal PSTN-adgang til Cloud Connect for [mangler kontekst/lokal adgang til Cloud Connect]:
-
Cloud Connect til partnervalg.
Se listen over Cloud Connect-partnere, og vælg blandt de tilgængelige partnere for din organisations placering.
-
Cloud Connect til validering.
Før PSTN-adgang for lokationer skiftes til Cloud Connect, skal forbindelsen til PSTN via den valgte Cloud Connect-partner verificeres og valideres. Til dette formål skal en testlokation være provisioneret med nogle testbrugere provisioneret på den pågældende testlokation. PSTN-adgang for denne testlokation indstilles derefter til Cloud Connect-partneren, før PSTN-forbindelsen valideres ved hjælp af testtelefonerne. Efter vellykket validering kan testlokationen deaktiveres.
-
Nummerportering.
For at forberede overgangen til Cloud Connect skal der afgives en porteringsordre for alle numre, der i øjeblikket er tildelt den PSTN-trunk, der afsluttes den. Alle numre skal porteres til Cloud Connect-partneren. For at opretholde tilgængelighed mellem lokationer skal alle numre fra alle lokationer porteres på samme tid.
-
Skift til Cloud Connect-partner.
På datoen for overgangen skal PSTN-adgang for alle lokationer indstilles til den cloudforbundne PSTN-udbyder, og indgående og udgående forbindelse skal verificeres.
Som beskrevet i PSTN-afsnittet i designkapitlet kan kunder også vælge at flytte deres PSTN-adgang til Cloud Connect i starten af overgangen ved hjælp af PSTN-trunking til hybridimplementeringer. For mere information, se PSTN-trunking til hybrid Webex Calling-implementeringer. I så fald sker PSTN-adgang under overgangen via den lokale gateway, og efter at alle brugere er flyttet, er der intet yderligere PSTN-relateret migreringstrin udover dekommissionering og de lokale gateways.
Optimer den lokale infrastruktur
Når alle brugere er blevet overført til, og alle slutpunkter er blevet overført til cloud-registrering (eller er blevet taget ud af drift), skal den relevante lokale infrastruktur opdateres, nu hvor cloud-opkald er i brug. Opdateringer af infrastrukturen omfatter:
-
Fjern DNS SRV-poster for opkaldskontrol og beskeder i det lokale miljø fra den/de lokale DNS-server(e), herunder cisco_uds._tcp.<domain>, cup_login._tcp.<domain>. Disse SRV-poster er ikke længere nødvendige til klienttjenesteopdagelse.
-
Fjern kantrelaterede DNS SRV-poster fra det offentlige DNS-system, inklusive collab_edge._tls.<domain>. Disse SRV-poster er ikke længere nødvendige til klienttjenesteopdagelse af samarbejds-edge-tjenester.
-
Opdater alle relevante DHCP-scoper for at fjerne valgmulighed 66 og valgmulighed 150. TFTP/boot serveradresser. Disse omfang er ikke længere nødvendige til registrering og download af konfiguration af slutpunktsopkaldskontrol.
-
Update/remove passende opkalds-peers i Lokalt Gateway/CUBE den rute ringer til og fra Unified CM. Disse opkalds-peers er ikke længere nødvendige til lokal opkaldsrouting.
-
Slet eller fjern alle virtuelle maskiner og klyngenoder and/or servere. Genbrug computerressourcer og hardware efter behov. Disse ressourcer er ikke længere nødvendige til opkaldsstyring og edge-tjenester.
-
Slet eller fjern alle virtuelle maskiner fra klyngenoden and/or servere. Genbrug computerressourcer og hardware efter behov. Disse ressourcer er ikke længere nødvendige til telefonsvarer og Unified Messaging-tjenester.
-
Oprydning: Efter migrering af PSTN-adgang til Cloud Connected PSTN kan PSTN-trunks, PSTN-gateways og Local Gateway deaktiveres.
-
For enhver eksisterende lokal E911-løsning skal du slette alle lokationer eller numre, der er migreret til, og når den fulde overgang er fuldført, skal du fjerne applikationens virtuelle maskiner eller servere. Genbrug computerressourcer og hardware efter behov. Disse ressourcer er ikke længere nødvendige til nødopkald og placeringstjenester.
-
DN'er, der tilhører migrerede brugere, bør placeres i en skjult partition for at undgå fejl i opkaldsrouting og for at sikre, at alle CSS'er har prioriteret adgang til cloudstien for de samme DN'er.
-
Opdater den fysiske afsendbare placering og netværkselementet i Horizon Mobility, når der sker ændringer. Almindelige aktiviteter, der kræver opdateringer, er:
-
Udskiftning af netværksswitch
-
Udskiftning af trådløst adgangspunkt
-
Ændringer i DHCP-omfang
-
Fysiske ændringer inde i bygningen (hvis der besluttes at cubical/office)
-
Udvidelse eller indskrænkning af fysisk kontorplads inde i en bygning.
-
Brug analyser og fejlfinding
tilbyder omfattende analyse- og fejlfindingsfunktioner, der hjælper dig med at visualisere og spore din implementering. Disse dækker mediekvalitet, detaljeret opkaldshistorik, opkaldskø, søgegruppe og analyser af automatisk omstilling. Et eksempel på mediekvalitetsanalyse er vist i figur mediekvalitetsanalyse.
Under fejlfinding kan hvert opkald foretaget med ses med detaljerede oplysninger om vigtige mediekvalitets- og signalrelaterede problemer for at hjælpe med at identificere medieproblemer samt mislykkede opkald, som vist i figur fejlfinding af mediekvalitet.
Fejlfinding kan også integreres med andre Cisco-produkter som ThousandEyes og Meraki-switche for at give en endnu rigere integreret oplevelse i Control Hub. For mere information om brug af Webex Calling analyser og fejlfinding, se Fejlfinding af Webex Calling-opkald i Control Hub.
