Implementeringsveiledning for migrering

Introduksjon

Før du begynner

Denne veiledningen er ment for team eller enkeltpersoner med erfaring med å konfigurere og administrere Cisco Unified Communications Manager (Unified CM) og Cisco-endepunkter, inkludert IP-skrivebordstelefoner, videoenheter, og Jabber-myke klienter. Gjennom dette dokumentet er det lenker til produkt- og støttedokumentasjon for å hjelpe deg.

Dette dokumentet fokuserer bare på overganger fra Unified CM til Webex Calling flerleietaker. Begrepet Webex Callingi dette dokumentet refererer alltid til Webex Calling flerleietaker.

Før du begynner migreringen fra Unified CM tilWebex Calling, er det viktig å ha en omfattende forståelse av Webex Calling løsningen og dens respektive komponenter. En vellykket migrering krever kjennskap til Webex Calling arkitek turen, tjenestemodellene, distribusjonsalternativene og tilknyttede funksjoner for å kartlegge eksisterende Unified CM arbeidsbelastninger riktig og utforme en effektiv overgangsplan.

En grundig forståelse av følgende Webex Calling komponenter er avgjørende for å informere om en effektiv overgangsstrategi og operativ beredskap.

Kontrollhub
Katalog- og brukerklargjøring
Webex Callingplattform
Støttede anropsendepunkter
PSTN-tilkoblingsalternativer
Webex Callingringeplan og nummerstyring
Sikkerhets- og samsvarsfunksjoner.

Hvis du vil ha mer informasjon, kan du se Cisco Preferred Architecture forWebex Calling.

Denne veiledningen vil fremheve verktøy og prosesser som skal brukes gjennom hele overgangslivssyklusen. Imidlertid kan en overgang fra lokale samtaler,Unified CM, til en ny plattform for skyanrop,Webex Calling, være en betydelig innsats med potensielle forretningsmessige, tekniske og komplekse utfordringer. For å hjelpe deg med å overvinne disse utfordringene har Cisco noen forskjellige alternativer tilgjengelig for å hjelpe deg med reisen din. Det er viktig å gå gjennom informasjonen i Enterprise Cloud Calling — Overføring av anrop og forstå hvert alternativ og hvordan hvert enkelt alternativ muligens kan hjelpe deg med din egen migrering.

Webex-migreringsverktøy: selvbetjente, gratis verktøy innebygd i Control Hub for å effektivisere overgangen til Webex Calling
Sertifiserte overføringsleverandører: Cisco-validerte programvare- og verktøyleverandører som har utviklet overføringsløsninger for å hjelpe Webex-partnere og kunder med komplekse og store migreringer. Disse løsningene kan bidra til å forenkle, administrere og akselerere overgangen til Webex Calling
Webex Setup Assist: en Cisco-ledet overføringstjeneste som veileder kunder og partnere gjennom Webex Calling distribusjonen og konfigurasjonen, som er nødvendig for å overføre Unified CM brukere og tjenester til. Webex Calling

Oversikt

Med veksten av skyleverte samarbeidstjenester, ønsker flere kunder å flytte sine eksisterende samarbeidsarbeidsbelastninger til skyen gitt løf tene om reduserte totale eierkostnader, forenklet administrasjon, kontinuerlig funksjonsleveranse, økt skala og overlegen pålitelighet iboende i skybaserte tjenester. Når kundene ønsker å gjøre overgangen fra lokale til skybaserte samarbeidstjenester, er det viktig for dem å forstå hva overgangen innebærer, og trinnene som kreves for å gjøre overgangen.

Formålet med dette dokumentet er å gi distribusjonsveiledning for kunder som spesifikt ønsker å gå fra lokalt Unified CM til Webex Calling i skyen. Denne distribusjonsveiledningen forutsetter at leseren har en grunnleggende forståelse av anropsovergangen mellom Unified CM ogWebex Calling, inkludert hva som endres når du foretar denne overgangen, og hva forskjellene er når du flytter anropsarbeidsmengden fra lokal til skyen. Før du fortsetter, sørg for at du har gjennomgått og er kjent med informasjonen som er tilgjengelig i overgangskartet. Dette overgangskartdokumentet gir informasjon om endringene og forskjellene i denne overgangen.

Som vist i figur Lokal samarbeidsarkitektur: samtalekontroll og ekstern tilgang inkluderer en typisk lokal distribusjon forskjellige samarbeidsinfrastruktur komponenter på nettverket, en samtal ekontrollplattform, en kantplattform, maskinvare- og programvareendepunkter, og i noen tilfeller til og med konferanse- og planleggingsplattformer. I Cisco- arkitekturen vil dette omfatte Unified CM samtalekontroll, Expressway for ekstern tilgang og business-to-business (B2B) edge-tjenester, Cisco Meeting Server/ Cisco Meeting Management for lokale konferanser, Unity Connection for talemeldinger og brukervendt maskinvare (Cisco IP-telefoner, Cisco Desk and Room video systemer) og programvare () IP-baserte endepunkter. Cisco Jabber Disse komponentene kan variere noe i noen miljøer, men dette er utgangspunktet for overgangen beskrevet i resten av dette dokumentet.

On-Premises Collaboration Architecture: Call Control and Remote Access — ***Lokal samarbeidsarkitektur: samtalekontroll og ekstern tilgang***

Arkitekturen vist i figur Lokal samarbeidsarkitektur: anropskontroll og ekstern tilgang er basert på Preferred Architecture (PA) for Cisco Collaboration Enterprise On-Premises Deployments. Hvis du vil ha mer informasjon om Enterprise On-premise, kan du se Ciscos foretrukne samarbeidsarkitekturer.

Før: Tabellen for lokale anropsinfrastrukturkomponenter viser nøkkelelementene Webex Calling i den lokale arkitekturen før overgangen til skyen.

Tabell 1. Før: Lokale anropsinfrastrukturkomponenter
Produkt	Beskrivelse
Unified CM	Lokal anropskontroll som gir enhetsregistrering og samtalerutingstjenester
Cisco Expressway-C/E	Edge-infrastruktur som gir mobil- og Remote Access (MRA) og business-to-business (B2B) funksjonalitet som gjør det mulig for eksterne endepunkter å koble seg sikkert fra utenfor organisasjonen. Expressway distribueres parvis for å gi brannmur kryssing for eksterne endepunkter.
Cisco møteserver (CMS), Cisco møteadministrasjon (CMM) og Cisco TelePresence Management Suite (TMS)	Lokal tale-, video- og nettkonferanseinfrastruktur som gir flerpunktmøter, møteadministrasjon og planleggingsfunksjoner. [Valgfritt]
Cisco Unity Connection	Lokal talemeldingsplattform som gir talepost og enhetlige meldingsfunksjoner. [Valgfritt]
Cisco Desk, Cisco Room, Cisco Board, Cisco IP-telefoner og Cisco Jabber	IP-baserte enheter som er registrert på Unified CM og gir mulighet for tale- og videosamtaler

Som illustrert i Figur Overgangsvedtak: lokal samtale til Webex Calling, kunder som har en lokal samtalekontroll med Unified CM skrivebords- og video-IP-endepunkter, kan velge mellom å overføre arkitekturen til en skyarkitektur. Webex Calling

Beslutningen må tas basert på kundens funksjonalitetskrav. Kunder som har følgende krav, bør vurdere nøye før de tar denne beslutningen, og kan til slutt bestemme seg for å beholde samtalekontrollen lokalt:

Telefonmodeller støttes ikke av Webex Calling
Komplekse eller mange integrasjoner med andre lokale systemer eller løsninger, spesielt der Webex Calling det er vanskelig å replikere disse integrasjonene med eller ingen tilsvarende alternative løsninger er tilgjengelige
Kompleks nummerplan, svært detaljerte tjenesteklasser eller begge deler
Begrenset, begrenset eller upålitelig Internett-tilgang
Strenge retningslinjer for personvern og eierskap
Overholdelseskrav for opptak og lagring av medier lokalt eller i land
Tredjepartsintegrasjoner uten levedyktig alternativ Webex Calling integrasjon
Kontaktsenterintegrasjoner der kontaktsenteret ikke flytter til skyen ennå.

Transition Decision: On-Premises Calling to Webex Calling — ***Overgangsvedtak: lokal anrop til Webex Calling***

Kunder som ønsker å begynne å utnytte skysamtaletjenester, bør vurdereWebex Calling. Denne skysamtaletjenesten lar kunden utnytte Webex globale arkitektur for skalering og tilkobling. Deltakere i bedriftsnettverket og eksterne deltakere utenfor bedriftsnettverket kan kommunisere ved hjelp av IP-baserte maskin vareendepunkter og/eller desktop- eller mobile myke klientapplikasjoner.

Dette dokumentet fokuserer på kunder med Unified CM distribusjoner for samtalekontroll som ønsker å forstå de generelle trinnene, hensynene og kravene for å aktivere Webex Calling distribusjon som vist i neste avsnitt.

Kjernekomponenter

Målarkitekturen for denne overføringen inkluderer flere nye komponenter. Dette inkluderer Webex Calling tjenesten for skybaserte anrop, Webex App, Cisco Directory Connector for identitetsintegrasjon og Local Gateway (LGW) for PSTN- tilgang, samt lokal til skybasert anropsintegrasjon. Cisco Calling Plans eller Cloud Connec ted PSTN (CCP) tilrettelagt av en Cloud Connect for Webex Calling partner er tilleggsalternativer for PSTN-tilgang.

Som vist i Figur A fter: Webex Calling Architecture, legges de nye komponentene (Webex Calling, Katalogkontakt, Lokal gateway og Overlevelsesgatewayen) til i den eksisterende lokale distribusjonen.

Etter: Tabellen for skyanropsinfrastrukturkomponenter viser de nye elementene i arkitekturen etter overgang til Webex.

Tabell 2. Etter: Infrastrukturkomponenter for skyanrop
Produkt	Beskrivelse
Webex Calling	Skybasert anropstjeneste levert fra Webex-plattformen og gir endepunktregistrering og samtaleruting
Cisco katalogkontakt	Windows-program som kjører på en Windows-domenemaskin som gir identitet ssynkronisering mellom bedriften lokalt Active Directory og identitetslageret til Webex-organisasjonen. For kunder som flytter fra lokal Active Directory til Entra ID, bruker identitetsintegrasjonen med Webex i stedet for Cisco Directory Connector Entra ID-veiviserappen.
Lokal gateway	En lokal gateway fungerer som en bro mellom kundens lokale enhetlige kommunikasjonsnettverk og Webex Calling skyen. Den kan distribueres lokalt eller hostes av en partner, og leverer PSTN- tilgang for skyregistrerte endepunkter, samt anropsintegrasjon mellom registrerte og sky Unified CM registrerte endepunkter. Cisco IOS-XE Integrated Services Router (ISR 1100- og 4000-serien), Cisco Catalyst 8200/8300-serien, Cisco Catalyst 8000V Edge- programvare og forskjellige sertifiserte tredjeparts Session Border Controllers (SBC) kan brukes som en LGW for en trinnvis migreringstilnærming.
Gateway for overlevelsesevne	Survivability Gateway (SGW) er en lokal nettverks-IOS-XE-basert gateway som gir tilbakekallingstjenester til endepunkter på stedet Webex Calling under nettverksbrudd.
Cisco anropsplan, Cloud Connect for Webex Calling	Cisco Calling Plan og Cloud Connect for Webex Calling er skybaserte alternativer for PSTN-tilgang for Webex Calling endepunkter. PSTN-tilgang tilrettelegges av en skybasert PSTN-leverandør og krever ikke lokalt utstyr.
Webex-appen	Klientapplikasjon som kjører på stasjonært OS (Windows, Mac) eller mobilt OS (Android, iOS) og registrert direkte på Webex Calling plattformen for anropsfunksjonalitet.

PPDIO prosessoversikt

PPDIO- prosessen står for forberede, planlegge, designe, implementere og optimalisere. Det er en strukturert Cisco-metodikk som veileder prosjekter fra første vurdering gjennom kontinuerlig forbedring, og sikrer effektive og vellykkede distribusjoner eller migreringer.

Generell beskrivelse av PPDIO

Forbered deg: Vurder det nåværende miljøet, samle krav og justere interessenter for å etablere et solid fundament.
Plan: Ut vikle detaljerte prosjektplaner inkludert tidslinjer, ressurser og risikoreduserende strategier.
Design: Arkitekt målløsningen skreddersydd til forretningsmessige og tekniske behov.
Implementere: Utfør distribusjonen eller migreringen i henhold til designet, validere funksjonalitet og ytelse.
Optimaliser: Forbedre løsningen kontinuerlig etter implementering ved å overvåke ytelse, foredle konfigurasjoner og utnytte automatiserings- og integrasjonsverktøy.

Bruke PPDIO for Unified CM til Webex Calling migreringsprosjekter

Ved overgang fra Unified CM til Webex Calling gir PPDIO-prosessen et klart veikart for å sikre en jevn og effektiv overgang:

Forberede

Vurdere eksisterende Unified CM miljø og migrasjonsberedskap
Samle inn detaljerte data om brukere, enheter, nettverk og avhengigheter
Samle inn stedsinformasjon inkludert beredskapsadresse, antall brukere, internet tilgang, PSTN-tilgang
Identifiser risikoer og definer prosjektomfang for å tilpasse alle interessenter.

Planlegg

Opprett en omfattende overføringsplan med batchplaner, ressurstildelinger og tidslinjer
Definere oppgaver som oppgraderinger av fastvare for enheter, lisensklarering og brukerinnføring
Koordiner migreringsvinduer med Cisco og partnere for å minimere forstyrrelser.

Utforming

Tilordne gjeldende Unified CM konfigurasjoner, nummerplaner og brukerprofiler til Webex Calling ekvivalenter
Utforme Webex Calling miljøet, inkludert PSTN-strategi (midlertidig og endelig), lokasjoner, brukerroller og integrasjonspunkter som Local Gateway (CUBE) og katalogsynkronisering
Planlegg for sameksistensscenarier der Unified CM og Webex Calling opererer samtidig under migrering.

Implementere

Bruk Control Hub-migreringsverktøy sammen med tredjepartsverktøy for å utføre endringer i enhetens fastvaremodus, funksjonskonfigurasjon og brukermigrering
Bruk masseoperasjoner og klargjøring ved hjelp av Webex API-er for å effektivisere store overføringer og konfigurasjoner
Utfør lisensklargjøring, enhetsregistrering og konfigurasjonsoppdateringer
Valider overføringssuksess gjennom testing og operativ verifisering.

Optimaliser

Kontinuer Webex Calling lig overvåke ytelse og brukeropplevelse
Avgrens konfigurasjoner og arbeidsflyter basert på driftsdata og tilbakemeldinger
Utnytt automatiserings- og integrasjonsfunksjoner for å forbedre effektiviteten og skalerbarheten
Avslutt eldre Unified CM komponenter etter behov og gi kontinuerlig støtte for dag-2-operasjoner.

Denne forbedrede PPDIO-tilnærmingen sikrer en kontrollert, gjennomsiktig og effektiv migrering fra Unified CM til, ved å utnytte Ciscos verktøyWebex Calling, API-er og partnerøkosystem for å opprettholde forretningskontinuitet og forbedre samarbeidsmulighetene.

PPDIO tilbakemeldingssløyfer

Oversikten på høyt nivå som er avbildet i figur iterasjoner mens du utfører PPDIO illustrerer en enkelt tilbakemeldingssløyfe fra optimalis eringsfasen tilbake til forberedel sesfasen. Dette betyr at det etter den første implementeringen er en kontinuerlig mulighet for kontinuerlig forbedring. Hver optimaliseringssyklus kan identifisere nye krav eller forbedringsområder, som kan adresseres gjennom påfølgende prosjekter eller initiativer. Disse individuelle prosjektene følger i sin tur hver den etablerte PPDIO (Prepare, Plan, Design, Implement, Optimize) livssyklusen. Denne iterative tilnærmingen sikrer at systemet forblir på linje med utviklende forretningsmål og teknologiske fremskritt, og fremmer en kultur med kontinuerlig raffinement og tilpasningsevne.

Iterations while executing PPDIO — ***Iterasjoner mens du kjører PPDIO***

Under gjennomføringen av PPDIO-prosessen er det vanlig at funn i de senere fasene nødvendiggjør revurdering og potensielt revisjon av beslutninger tatt i tidligere stadier. For eksempel kan problemer som oppstår i implementeringsfasen, for eksempel identifisering av tvetydigheter i design eller manglende detaljer, avsløre at visse aspekter ikke ble fullstendig adressert i designfasen. I slike tilfeller blir det nødvendig å gjenta tilbake til den aktuelle tidligere fasen for å løse disse problemene før du fortsetter. Denne iterative tilbakemeld ingsmekanismen, som illustrert i figur Unified CMassistert PPDIO-prosess, sikrer at løsningen blir grundig validert og raffinert, og til slutt bidrar til en mer robust og effektiv distribusjon.

Unified CM assisted PPDIO process — ***Unified CMassistert PPDIO prosess***

Når du foretar en overgang fra Unified CM tilWebex Calling, kan hver fase av PPDIO-prosessen ha betydelig nytte av informasjon samlet inn fra det eksisterende Unified CM miljøet. For eksempel kan omfattende varebeholdninger av brukere, telefonnumre, anrops funksjoner og oppringeplankomponenter hentes ut fra gjeldende Unified CM konfigurasjon. Disse dataene supplerer informasjon gitt direkte av interessenter og hjelper til med å effektivisere planleggings- og designaktiviteter. Å utnytte passende verktøy for å automatisere dat autvinning og analyse forbedrer ikke bare nøyaktigheten, men akselererer også den generelle prosessen. Ved å utnytte innsikt fra den eksisterende distribusjonen, Webex Calling kan overgangen til utføres mer effektivt enn en tradisjonell greenfield-implementering, mens den fortsatt følger den struktur erte PPDIO-metodikken. Denne prosessen er illustrert i figur Unified CMassistert PPDIO-prosess.

Migrasjonstilnærming

Når du planlegger overgangen fra lokal Unified CM til lokalWebex Calling, må du bestemme hvordan du vil tilnærme deg denne reisen. Først må du bestemme om migr eringen vil være en flash-cut (alt på en gang) eller en trinnvis tilnærming (migrere grupper av brukere/enheter over en lengre periode).

Ved å gjøre en flash-cut- migrering flyttes alle brukerne og enhetene dine raskest. Med denne metoden flytter du alle brukere og enheter fra lokalt Unified CM til Webex Calling samtidig. I hovedsak er det ett enkelt migrasjonsvindu for alle brukere og enheter. Etter at denne overføringen er fullført, vil alle brukerne og enhetene dine være på Webex Calling plattformen, og all Unified CM infrastrukturen din kan tas ut av drift. Mange organisasjoner kan imidlertid ikke bruke denne tilnærmingen på grunn av omfanget og størrelsen på anropsdistribusjonen.

Den andre tilnærmingen er en trinn vis migrasjon. De fleste organisasjoner vil bruke denne tilnærmingen da den gir bedre kontroll, styring og skalering med migreringen. Den er også bedre egnet for større UC-distribusjoner og/eller distribusjoner på tvers av flere regioner. Derfor fokuserer dette dokumentet på den trinn vise tilnærmingen med to trinn i overgangen.

Som vist i figuren nedenfor Faset anropsovergang: Hybrid og sky, resulterer den første overgangsfasen (fase 1) i en sameksistensdistribusjon med doble anropsmiljøer. I denne fasen blir noen brukere, enheter og myke klienter overført til Webex Calling mens andre fremdeles er på den lokale anropskontrollenUnified CM. Den siste overgangsfasen (fase 2) resulterer i et rent sky anropsmiljø der alle brukere, enheter og myke klienter har blitt fullstendig overført til Webex Calling plattformen.

Hvor lang tid det tar en organisasjon å fullstendig gå over til skyanrop, vil variere basert på gjeldende distribusjon. I noen tilfeller kan en organisasjon foreta den første overgangen og forbli i sameksistens dual call control fase (fase 1) i en lengre periode (måneder eller til og med år), mens i andre tilfeller kan en organisasjon fullstendig gå over til Webex Calling (fase 2) i en veldig kort periode (uker eller måneder). Dette dokumentet er ment å dekke begge faser (fase 1 - sameksistens og fase 2 - fullstendig overgått).

Phased Calling Transition: Hybrid and Cloud — ***Trinnvis anropsovergang: hybrid og sky***

Det er mulig at noen organisasjoner kan opprettholde en sameksistens med dobbel samtalekontroll distribusjon på ubestemt tid uten planer om noen gang å fullstendig overgå til skyanrop.

Den andre vurderingen er hvordan du vil overføre brukere, enheter og myke klienter fra den lokale samtal ekontrollen til skysamtalekontrollen. Den anbefalte tilnærmingen er en 3-fas et overgang. Figuren Anbefalt 3-faseovergang nedenfor bryter ned denne tilnærmingen i 3 faser.

Recommended 3-Phase Transition — ***Anbefalt 3-faseovergang***

Før migrering: Denne fasen fokuserer på å gjøre både Webex og Unified CM miljøene klare for migreringen. Dette handler ikke om å ringe spesifikk planlegging eller konfigurasjoner, og fokuserer på å fullføre aktiviteter som kan gjøres nå og før et Webex Calling migreringsprosjekt starter. Målet er å bygge grunnlaget for at de to miljøene skal forberede seg på migrasjonen.

Migrasjonsforberedelse: Denne fasen begynner innsatsen for å forberede migreringen til Webex Calling. Her må forretningsmessige og tekniske krav gjennomgås og oppdateres. Ikke bare gjør et løft og skift av det som for øyeblikket er implementert med, Unified CM og omdefiner i stedet de forretningsmessige og tekniske kravene som bedriften din trenger i dag og i fremtiden ved å utnytte kraften til. Webex Calling I tillegg er dette fasen der du vil fullføre design, konfigurasjons planlegging og migreringsplanlegging/tidsplan.

Migrering (utrulling og avvikling): Denne fasen er der den faktiske migreringen av brukere, enheter, telefonnumre og myke klienter skjer. Som diskutert ovenfor kan denne fasen fullføres for alle på en gang (flash-cut) eller over flere endringsvinduer (fas et kutt). Adopsjonsplaner for sluttbrukere, opplæring og kommunikasjon er avgjørende, slik at brukerne dine er klar over endringene, hvordan de bruker den nye samtaleplattformen, og vet når en dringen vil skje. Det siste trinnet er å deaktivere all lokal UC-infrastruktur som ikke lenger brukes.

Fasen før migrering har aktiviteter (påkrevd, anbefalt og valgfritt) som du kan begynne å jobbe med umiddelbart. Det anbefales å fullføre disse før heller enn senere og helst før prosjektet begynner. Noen av aktivitetene kan ta lengre tid å fullføre, og å starte dem tidligere vil derfor bidra til å effektivisere det faktiske overføringsprosjektet ditt.

Figuren Pre-Migration Activi ties nedenfor fremhever fem spesifikke kategorier av aktiviteter som er relatert til en Webex Calling migrering.

Forberede

Forretnings- og tekniske krav

Når du planlegger en migrering fra til, er det avgjørende å grundig samle både tekniske og forretningsmessige krav i planleggingsfasen. Dette trinnet sikrer at migrering stemmer overens med organisasjonens operasjonelle mål og tekniske evner, og minimerer risiko og forstyrrelser.

Hvorfor det er viktig å samle krav:

Justerer forretningsmessige mål: For ståelse av forretningsbehov hjelper deg med å skreddersy migreringen for å støtte viktige arbeidsflyter, brukeropplevelse og vekstplaner.
Sikrer teknisk kompatibilitet: Å identifisere tekniske krav tidlig forhindrer integrasjonsproblemer med eksisterende infrastruktur, nettverk og endepunkter.
Tilrettelegger for ressursplanlegging: Tydelige krav bidrar til å estimere tidslinjer, kostnader og nødvendige ressurser nøyaktig.
Reduserer risiko: Tidlig oppdagelse av potensielle utfordringer gir mulighet for proaktive løsninger, reduserer nedetid og serviceavbrudd.

Forretningskrav

Typiske forretningskrav inkluderer:

Antall brukere og steder som skal overføres
Ønskede funksjoner og tjenester (eksempel samtaleruting, telefonsvarer, konferanser, automatiske svarmenn, samtal ekøer)
Retningslinjer for samsvar og sikkerhet
Budsjettbegrensninger og kostnadsforventninger
Brukeropplæring og støttebehov
Overføringstidslinje og forretningskontinuitetshensyn.

Å samle ønskede funksjoner og tjenester er et kritisk skritt for å sikre at det nye systemet oppfyller forretningsbehov. Når du samler disse kravene, er det viktig å ikke bare vurdere hva som for øyeblikket er konfigurert i, men prøve å samle de faktiske kravene fra forretningsenhetene som skal bruke systemet. Ellers er det fare for at planen er basert på langsiktige forutsetninger. Sørg for å evaluere flere eller forbedrede funksjoner som er tilgjengelige i som kanskje ikke finnes i, for eksempel skybaserte anrop, avanserte samtalekøer, , og. Dette hjelper deg med å utnytte de fulle fordelene med skyplattformen.

Når du evaluerer gjeldende konfigurasjon i, er det viktig å erkjenne at ikke alle eksisterende innstillinger kan forbli nødvendige på grunn av utvikl ende krav gjennom systemets livssyklus. Fokuset bør være på å identifisere og beholde bare de konfigurasjonene som samsvarer med nåværende og fremtidige behov for distribusjonen.

Fokuser mer på det du trenger enn det du har.

Samsvars- og sikkerhetspolicyer er viktige hensyn under overføringen fra til Webex Calling for å sikre at det nye skybaserte kommunikasjonssystemet overholder juridiske, forskrift smessige og organisatoriske standarder.

Overholdelse av forskrifter: Organisasjoner må verifisere at de oppfyller bransjespesifikke forskrifter som GDPR, HIPAA eller SOX, og adresserer krav til personvern, oppbevaring og håndtering av data, samt landsspesifikke mandater knyttet til dataopphold, bompengeomgåelse og medielokalitet.
Datasikkerhet: Sikre at tale- og signaldata krypteres både i transitt og i hvile for å beskytte mot avlytting eller uautorisert tilgang.
Tilgangskontroller: Definere og håndheve brukerautentisering, autorisasjon og rollebasert tilgang for å forhindre uautorisert bruk av kommunikasjonsressurser.
Tilsyn og overvåking: Im plementering av logging og overvåkingsfunksjoner for å spore tilgang og bruk for samsvarsrevisjoner og undersøkelser av sikkerhetshendelser.
Retningslinjejustering: Tilpass overføringen med eksisterende sikkerhetspolicyer for bedriften, inkludert endepunktssikkerhet, nettverkssegmentering og hendelsesresponsplaner.
Leverandørsikkerhetsforsikring: Evaluering av Ciscos sikkerhetssertifiseringer og samsvarserklæringer for å sikre pålitelighet.

Å håndtere disse retningslinjene for samsvar og sikkerhet i planleggingsfasen bidrar til å redusere risiko, unngå rettslige straffer og opprettholde integriteten og konfidensialiteten til kommunikasjonen gjennom og etter overføringen.

Brukeropplæring og støttebehov er viktige komponenter under migreringen fra til for å sikre en jevn overgang og brukeradopsjon. Viktige hensyn inkluderer:

Opplæringsprogrammer: Utvikle skreddersydde treningsøkter for ulike brukergrupper (sluttbrukere, administratorer, helpdesk-ansatte) for å gjøre dem kjent med funksjoner, brukergrensesnitt og nye arbeidsflyter.
Dokumentasjon: Gi klare, tilgjengelige brukerveiledninger, vanlige spørsmål og hurtigreferans emateriell, inkludert ressurser for nyheter og forskjellige ressurser og trinnvise veiledninger før og etter (i video- eller hurtigveiledningsformat), for å støtte brukerne når de tilpasser seg den oppdaterte opplevelsen etter migrering.
Endringsadministrasjon: Kommuniser endringer proaktivt for å håndtere brukernes forventninger og redusere motstand.
Støttestruktur: Etablere et dedikert støtteteam eller opptrappingsbane for å løse brukerproblemer raskt under og etter overføringen.
Pågående utdanning: Planlegg for kontinuerlige opplæringsoppdateringer når nye funksjoner eller oppdateringer sli ppes i.
Tilbakemeldingsmekanismer: Implementere kanaler for brukere for å rapportere problemer og gi tilbakemelding for å forbedre opplærings- og støtteprosesser.

Å adressere disse trenings- og støttebehovene i planleggingsfasen bidrar til å minimere forstyrrelser, forbedrer brukernes tillit, og maksimerer fordelene ved å migrere til.

Tekniske krav

Flere viktige tekniske krav må samles inn og dokumenteres for en vellykket migrering fra til, inkludert detaljer for:

Nettverksberedskap og båndbreddekapasitet

En omfattende nettverksvurdering er avgjørende for å sikre at din eksisterende infrastruktur kan støtte det nye Webex Calling miljøet. Dette inkluderer:
- Båndbreddeanalyse: Evaluering av nåværende og projisert båndbreddebruk for å håndtere tale-, video- og datatrafikk uten overbelastning.
- Kvalitet på tjenesten (QoS): Implementering av QoS-policyer for å prioritere taletrafikk og minimere ventetid, jitter og pakketap.
- WAN og Internett-tilkobling: Verifisere at WAN-koblinger og internettforbindelser oppfyller kravene for skybaserte anrop, inkludert redundans- og failover-funksjoner.
- Brannmur- og NAT-konfigurasjon: Sikre at brannmur- og NAT-innstillinger tillater nødvendig signalering og medietrafikk for.
Integrasjon med eksisterende system

Sømløs integrasjon med eksisterende forretningssystemer er avgjørende for brukeropplevelse og kontinuitet i arbeidsflyten:
- Katalogtjenester: Vurdering av integrasjon med en bedriftskatalog for automatisk klargjøring og godkjenning av brukere.
- CRM og forretningsapplikasjoner: Identifis ere integrasjonspunkter med kunde forholdsstyringssystemer og andre forretningskritiske applikasjoner.
- Legacy PBX-samarbeiding: Planlegging for sameksistens eller trinnvise migrerings strategier hvis noen eldre telefonisystem vil forbli under overgangen.
Endepunktkompatibilitet og klargjøring

Alle endepunkter, inkludert skrivebordstelefoner, softphones og mobile enheter, bør evalueres for kompatibilitet:
- Enhetsstøtte: Bekreft at eksisterende IP-telefoner og enheter støttes av eller identifiserer nødvendige erstatninger.
- Klargjøringsprosesser: Etablere automatiserte eller strømlinjeformede klargjøringsm etoder for effektiv onboarding av endepunkter.
- Fastvare- og programvareoppdateringer: Planlegging av nødvendige oppdateringer for å sikre interoperabilitet og sikkerhet.
Sikkerhetskonfigurasjoner og krypteringsstandarder

Sikkerhet er avgjørende i skykommunikasjon:
- Kryptering: Håndheve ende-til-ende-kryptering for signalering og mediestrømmer, i tråd med Ciscos beste sikkerhetspraksis.
- Autentisering og tilgangskontroll: Im plementering av sikre autenti seringsmekanismer (for eksempel SSO, multifaktorautentisering) og granulære brukertilgang skontroller.
- Overholdelse: Sikre at løsningen oppfyller relevante regulatoriske standarder og brans jestandarder (f.eks. GDPR, HIPAA).
- Sikkerhetsovervåking: Integrering med SIEM-verktøy og konfigurering av varsling for potensielle sikkerhetshendelser.

Tabell 1. Eksempelvurdering
Krav	Viktige hensyn
Nettverksberedskap og båndbredde	Båndbredde, QoS, WAN/Internett, brannmur/NAT
Integrasjon med eksisterende systemer	Katalog, CRM, PBX, E-post/kalender
Endepunktkompatibilitet og klargjøring	Enhetsstøtte, klargjøring, fastvareoppdateringer
Sikkerhetskonfigurasjoner og kryptering	Kryptering, autentisering, samsvar, sikkerhetsovervåking
Brukeropplæring og endringsledelse	Opplæringsprogrammer, dokumentasjon, endringskommunikasjon
Nummerportabilitet og nummerplan	Nummermigrering/-portering, nummerplanoversettelse
Tredjepartsintegrasjoner	Personsøking, kontaktsenter, faks, analoge enheter

Nettverksberedskap og krav

Nettverksberedskap er avgjørende for en vellykket migrering til en hvilken som helst skybasert anropsløsning som. Dårlig nettverksplanlegging kan føre til forringet samtalekvalitet, tapte samtaler og ulykkelige brukere. Kunder må gjennomføre en nettverksvurdering før de migrerer til. Det anbefales å bekrefte tilgjengeligheten av nettverksbåndbredde for forventet anrops volum, sikre at kravene til tjenestekvalitet (QoS) er oppfylt, og forstå de forskjellige portene som må åpnes i kantbrannmuren (e).

Pålitelig nettverkstilkobling med tilstrekkelig servicekvalitet (båndbredde, pakketap, RTT) er et grunnleggende krav for å sikre best mulig brukeropplevelse fra ende til ende for alle tale- og videokompatible endepunkter, klienter og applikasjoner som bruker.

Kunder og partnere har tilgang til tilkoblingsmuligheter utover OTT-Internett (Over-the-Top) som kan optimalisere tilkoblingen til å inkludere Webex Edge Connect. Hvis du vil ha mer informasjon om Webex Edge Connect- designdetaljer, kan du se Cisco Preferred Architecture for Webex Edge Connect forWebex Meetings, Calling Multi-Tenant og Dedikert fore komst.

Kunder kan bruke cScan for nettverksvurdering som gir informasjon om kundens nettverkskvalitet, hvor mange samtaler som kan etableres, ventetid og så videre. Hvis du vil ha mer informasjon om cScan-verktøyet, kan du se Bruke cScan til å teste Webex Calling nettverkskvaliteten.

For å sikre at nettverket er klart for overføring til, bør du vurdere følgende sjekkliste:

Båndbreddeplanlegging

Beregn samtidige anrop per nettsted for å sikre at du har nok oppstrøms og nedstrøms båndbredde og inkludere takhøyde for annen forretningskritisk trafikk og fremtidig vekst.

Bånd Webex Callingbreddeberegningstab ellen for samtaletype viser samtaletypene som er tilgjengelige med en distribusjon sammen med kodeken og maksimal båndbredde som kreves for hver anropstype. Som vist i tabellen for bånd Webex Calling breddeberegninger av anropstypen, kan den nødvendige båndbredde for lydanrop for hver anrop stype beregnes ved å bruke følgende generelle formel:

Antall forventede samtidige anrop * Båndbredde per samtale basert på kodek = Nødvendig nettverksgjennomstrømning.

Tabell 2. Webex Callingbåndbredde beregninger av anropstype
Samtaletyper	Codec - båndbredde	Båndbreddeberegninger
/Skrivebordstelefon ->	OPUS - 70 kbps	Antall samtidige anrop* 70 kbps = Nødvendig nettverksgjennomstrøm ning
/Skrivebordstelefon -> Skrivebordstelefon	OPUS — 70 kbps	Antall samtidige anrop* 70 kbps = Nødvendig nettverksgjennomstrøm ning
/Skrivebordstelefon -> PSTN via LGW	G.711 — 80 kbps	Antall samtidige anrop* 80 kbps = Nødvendig nettverksgjennomstrøm ning
/Skrivebordstelefon -> PSTN via Cloud PSTN (f.eks. Cisco-anropsplan)	G.711 — 80 kbps	Antall samtidige anrop* 80 kbps = Nødvendig nettverksgjennomstrøm ning
/Skrivebordstelefon -> Enterprise via LGW	G.722 — 80 kbps	Antall samtidige anrop* 80 kbps = Nødvendig nettverksgjennomstrøm ning
/Skrivebordstelefon -> telefonsvarer	OPUS — 70 kbps	Antall samtidige anrop* 70 kbps = Nødvendig nettverksgjennomstrøm ning

Ved å summere den samtidige nødvendige nettverksgjennomstrømning per anrop stype, kan det totale potensielle båndbreddebehovet for et bestemt sted bestemmes.

Alle anropsben er alltid forankret på tilgangs-SBC-ene. For å bestemme den nødvendige internettbåndbredde for et gitt sted, må ikke bare samtalene mellom lokasjonene vurderes, men også intra-lokasjonsanrop og samtaler til og fra en lokal gateway på det stedet. For eksempel vil en samtale mellom to MPP-telefoner trenge opptil 2 x 70 kbps full dupleks på stedets internetttilgang.

Tabellen med eksempler på Webex Calling båndbreddeberegning viser et eksempel på en fullstendig båndbred deberegningsøvelse, forutsatt at alle enhetene er på samme sted.

Tabell 3. Webex Callingbåndbreddeberegningsek sempler
Samtaletyper	Antall samtidige samtaler	Total båndbredde
Webex-app/skrivebordstelefon → Webex-app	15	2 * 15 * 70 kbps = 2100 kbps
Webex-app/skrivebordstelefon → Skrivebordstelefon	15	2 * 15 * 70 kbps = 2100 kbps
Webex-app/skrivebordstelefon → PSTN via LGW	50	2 * 50 * 80 kbps = 8000 kbps
Webex-app/skrivebordstelefon → PSTN via Cloud Connect for Webex Calling	0	0* 80 kbps
Webex-app/skrivebordstelefon → Enterprise via LGW	15	2 * 15 * 80 kbps = 2400 kbps
Webex-app/skrivebordstelefon → Talepost Webex Calling	5	5 * 70 kbps = 350 kbps
Totalt antall anrop/båndbredde	100 samtaler	14 950 kbps/14,95 Mbps

Alle båndbreddeverdier i tabellene ovenfor refererer til IP-båndbredde. Koblingsbåndbredde er høyere avhengig av WAN-innkapslinger.
Båndbredden i tabellene ovenfor er for lydan rop. For båndbredde for videosamtaler støtter Webex-appen og MPP 8845/65-telefonene H.264-video med maksimal oppløsning på 720p med en maksimal båndbredde på 1500 kbps per samtale . Mengden båndbredde som forbrukes på et hvilket som helst punkt under samtalen vil imidlertid variere basert på variabel bithastighet iboende i videokommunikasjon.

Kvalitet på tjenesten (QoS)

Implementere QoS-policyer i det lokale miljøet for å prioritere sanntidstrafikk, og sikre at QoS opprettholdes på tvers av svitsjer, rutere og brannmurer.
Mål for ventetid, jitter og pakketap

Følgende terskler anbefales for optimal talek valitet når samtaler går over-the-top (OTT) og over internett:
- Latens - mindre enn 100 ms enveis
- Jitter - mindre enn 10 ms
- Pakketap - 0,5% eller mindre.
Brannmur og NAT

Kontroller at brannmuren er konfigurert til å tillate trafikk som oppført i artikkelen som er tilgjengelig under Portreferanseinformasjon for Webex Calling. Tillat i tillegg tilgang til domener og IP-områder som er oppført i samme guide, og unngå SIP ALG da det forstyrrer SIP-signalering. Medietra fikk gjennom proxyer bør unngås.
DNS og NTP

Sørg for riktig DNS-oppløsning av domener og pålitelige NTP-servere for å synkronisere enhetsklokker for TLS-sertifikatbekreftelse og logging.
Failover-planlegging

Vurder eksisterende leverandørdatatilkoblinger (MPLS, SD-WAN og så videre) og planlegg generelt for direkte internettilgang på hvert sted i distribusjonen. Planlegg redundante internett koblinger der høy tilgjengelighet er nødvendig. Fordi du vil konsumere skybaserte tjenester, er pålitelig internett forbindelse med tilstrekkelig båndbredde et grunn krav. Du bør vurdere å gjøre denne overgangen på nytt hvis organisasjonens lokasjoners internettforbindelse (er) generelt ikke er pålitelig med lav ventetid og tilstrekkelig gjennomstrømning opp og nedstrøms.
Nettstedets overlevelsesevne

Nettstedsoverlevelsesevne sikrer at virksomheten din alltid er tilgjengelig, selv om nettverkstilkoblingen går i stykker. Site Survivalability bruker en gateway i det lokale nettverket for å tilby en reserveanropstjeneste til endepunkter på stedet for situasjoner der nettverkstilkoblingen går i stykker. Vurder nettstedets overlevelsesevne med en lokal Survivalability Gateway (SGW) hvis forretningskrav krever kontinuerlig samtale i tilfelle nettverksbrudd. For mer informasjon om kontroll av nettstedets overlevelsesevne, se Nett stedets overlevelsesevne for. Webex Calling

Konfigurere skytilkoblet UC

Cloud Connected UC (CCUC) er en skybasert administrasjons- og analyseløsning designet for å gi sentralisert synlighet, administrasjon og innsikt for distribusjoner både lokalt (for eksempel) og sky (Unified CM). Det fungerer som en bro mellom tradisjonelle lokale miljøer og Ciscos skytjenester, og støtter organisasjoner gjennom hele migrerings reisen fra til.

Under overgangen til, CCUC spiller en viktig rolle i å effektivisere migreringsprosessen ved å legge til rette for inn samling av omfattende data fra den eksisterende Unified Communications-distribusjonen. CCUC bistår med viktige overgangsoppgaver som migrering av enheter, funksjoner og bruker kontakter, samt automatisering av firmwareoppdateringer for støttede IP-telefoner. Ved å gi sentralisert synlighet og administrasjon bidrar CCUC til å sikre en jevnere og mer effektiv migreringsopplevelse.

Cisco anbefaler på det sterkeste at CCUC distribueres og distribueres tidlig i overgangsprosjektet, ideelt før eller under forberedelsesfasen. Dette vil muliggjøre innsikten og mulighetene som trengs for å grundig vurdere, lagre og planlegge for påfølgende migrering saktiviteter og for å starte reisen til og fremtidige hybridfunksjoner.

Vurdering av dagens miljø

En viktig aktivitet i planleggingen av overføringen er å vurdere gjeldende lokale miljø og distribusjon. Dette gir innsikt i hvilke potensielle endringer som kan være nødvendige for å lykkes med overgangen til. Det lar deg også vurdere nøkkelelementene i plattformen i forhold til den eksisterende lokale distribusjonen. Du kan bruke denne informasjonen til å identifisere hvilke spesifikke oppgaver som kreves for overgangen, og hvilke endringer du vil gjøre for å oppfylle forretningsmessige og tekniske krav og brukstilfeller.

Følgende aspekter er viktige å gjennomgå som en del av denne innsatsen.

Lisensiering

Å forstå gjeldende lisensieringsstruktur for den eksisterende distribusjonen er nøkkelen når du forbereder migrering til. Utfør en lisensvurdering av følgende områder av din eksisterende lokale Cisco- løsning.

Plattform

Evnen til å fullt ut formulere hva som for øyeblikket er lisensiert på kjerneplattformen din, vil være avgjørende når du jobber med kontoteamet eller partneren din for å finne den beste veien til fleksibel lisensiering. er lisensiert ved hjelp av flex-lisensiering. Hvis du vil ha mer informasjon om fleksibel lisensiering, kan du se Cisco Collaboration Flex Plan.
Brukere og enheter

Identifiser hvilken lisenskategori eksisterende brukere og enheter krever. Dette vil bli brukt til å bestemme hvilken type lisens som kreves for brukerne og enhetene. tilbyr flere lisenstyper, inkludert Professional- og Standard-lisenser for brukere og Professional- og fellesområdelisenser for arbeidsområder. Hvis du vil ha mer informasjon om enhetslisensiering, kan du se databladet som er tilgjengelig på Enhetslisensiering.
Lokal gateway

Hvis Cisco Unified Border Element (CUBE) kreves for PSTN-tilgang for denne overgangen, må CUBE-lisensiering også vurderes. CUBE-lisensiering shensyn dekkes senere i dette dokumentet.

Steder/steder

Antall og typer områder (store sentrale, regionale, filialer osv.) innenfor den eksisterende distribusjonen bør vurderes når du planlegger denne overgangen. En full forståelse av de eksisterende distribusjonsstedene vil hjelpe deg med strategisk planlegging for en vellykket overgang, spesielt når det gjelder å bestemme hvilke nettsteder som skal migreres og i hvilken rekkefølge. Å forstå detaljerte krav til nummerplan (nummerering, oppringingsvaner, begrensningsklasser og så videre), nettstedsnettverkstilkobling og båndbredde (Internett, WAN, LAN) og PSTN-tilgang (lokal eller sentralisert, IP eller TDM) for hvert nettsted vil være avgjørende når du tar migreringsbeslutninger. Hvis du vil ha mer informasjon om vanlige distribusjonsmodeller og viktige hensyn, kan du se informasjonen om samarbeidsdistribusjonsmodeller som er tilgjengelig i Collaboration SRND.

En annen viktig distribusjonshensyn når du overgår til, er tilgjengelighet. har forskjellige funksjoner, abonnementer og enheter som er tilgjengelige avhengig av hvor distribusjonen din befinner seg. Hvis du vil ha mer informasjon om geografisk tilgjengelighet, kan du se Hvor er Webex tilgjengelig? .

Til slutt er det viktig å forstå hvilken innvirkning overgangen til vil ha på andre samarbeidstjenester. Basert på formålet med dette dokumentet er den generelle antagelsen at hvis eksisterende samarbeidstjenester utenfor anropsarbeids mengden skal opprettholdes, forventes overgang til fase 1 hybriddistribusjon nevnt ovenfor. Eksempler på samarbeidstjenester som kan kreve hybrid distribusjon inkluderer lokalt kontaktsenter som ennå ikke er migrert til Webex kontaktsenter, og tette integrasjoner i systemer som personsøkingssystemer og fakturering. Hvis du vil ha mer informasjon om overgangen til flere arbeidsbelastninger og tjenester for samarbeid, kan du se Samarbeidsoverganger.

Inventar eksisterende enheter/klienter

Før du starter overgangen, er det viktig å lagre eksisterende maskinvare- og programvareendepunkter. Å ha en fullstendig liste over enhetstyper/modeller, maskinvareversjoner, operativsystemtyper og mengder for myke klienter vil sikre at du kan planlegge tilstrekkelig for overgang av enhetene og redusere virkningen for de enhetene som ikke kan migreres til skyanrop. Inventaret skal brukes til å bestemme enhetene som skal overgå og enhetene som skal byttes ut før over gangen.

Skrivebordstelefoner

For skrivebordstelefoner med lyd og video støttes bare skrivebordstelefonene i 6800, 7800, 8800 og 9800-serien. Dette er et delsett av Cisco IP-telefoner som støttes med. Det er noen modeller og versjoner av 6800, 7800 og 8800-telefonene som ikke kan brukes med. Hvis du vil ha mer informasjon om hvilke modeller og maskinvareversjoner som støttes, kan du se Støttede enheter for Webex Calling.

Cisco 6800-seriens IP-telefoner kan ikke oppgraderes fra Enterprise firmware til Multiplatform (MPP) firmware, som kreves for. Derfor må alle 6800-telefoner som er registrert for kjørende bedriftsfastvare byttes ut med en 6800 MPP-modell eller med en annen støttet telefonmodell.

Cisco 7800- og 8800-seriens IP-telefoner må oppgraderes til Multiplatform Phone (MPP) firmware før overgang og registrering av dem til. Hvis du vil finne ut hvilke 7800- og 8800-modeller og maskinvareversjoner som støtter MPP-fast varen, kan du se Konvertere IP-telefoner i Cisco 7800- og 8800-serien mellom Enterprise - og MPP-fastvare.

8845, 8865 og 8865NR har nådd slutten av salget og anbefales ikke å migrere til.

Eldre versjoner av 8800-seriens telefoner (8811, 8841, 8851, 8851NR, 8861) anbefales ikke å bruke med. Webex Calling Telefoner med maskinvareversjoner VID 14 eller tidligere vil registrere seg med, men kan oppleve noen ytelsesproblemer på grunn av maskinvaren.

9800-seriens bordtelefoner kjører PhoneOS, som støtter både og registrering. Derfor kan disse telefonene overføres til uten fastvareoppgradering.

Alle andre IP-telefoner må byttes ut med telefoner i 6800, 7800, 8800 eller 9800-serien som støttes av. Webex Calling Hvis du vil ha mer informasjon om støttede IP- og skrivebordstelefoner med, kan du se artikkelen under Støttede enheter for Webex Calling.

Videoendepunkter

Endepunkter for personlige og romvideo, inkludert Cisco Board-serien, Room-serien og Desk- serien, kan SIP-registreres naturlig til. Alle disse endepunktene som må foreta lyd- og/eller PSTN-anrop krever en anropslisens:

Delte enheter i konferanserom, møteplasser osv. krever enten en Professional Workspace- eller Workspace-lisens.

En sluttbrukers personlige enhet krever en profesjonell eller standard lisens.

Bestem hvor mange videoendepunkter som er registrert til og brukes til å foreta lydanrop. Det er mulig at noen av videoendepunktene bare kan brukes til å delta i møter eller foreta SIP-videosamtaler. I begge tilfeller må sluttpunktene fortsatt migreres til før serverne tas ut av drift, men dette vil bidra til å avgjøre hvor mange av dem som trenger lisenser for å fortsette å ringe.

Når videoenheter flyttes fra registrering til, vil URI-en for disse endepunktene endres ettersom de nå er skyregistrert.

Telefonmodeller 8845, 8865 og 8875 er personlige video telefoner som støttes med.

Myke klienter

Det er den eneste myke klienten som støttes av, i motsetning til Unified CM som støtter både Webex-appen og Jabber, og er den nye standard myke klienten for sluttbrukere.

Avhengig av distribusjonsmodus (er) som er implementert for Jabber (modus for bare IM, bare telefon og/eller full UC-modus), kan det hende du også må vurdere overgangen av arbeidsbelastningene Meldinger og/eller Møter fra Jabber til. Den kan distribueres i telefon modus hvis den vil bli brukt som en klient som kun ringer, eller den kan distribueres som full Webex Suite hvis andre arbeidsbelastninger, f.eks. Webex Messagingog/ellerWebex Meetings, blir overført til appen med anrop.

Det forbedrer sluttbrukerens opplevelse ved å tilby AI-funksjoner som lyd/ videointelligens, samtaletranskripsjon og andre. Hvis du vil ha mer informasjon, kan du se https://www.webex.com/all-new-webex.

Før du flytter brukere til, må du overføre Jabber-klientene til. Du har to alternativer for å fullføre denne overgangen.

Før du overfører dem til

Når du overfører dem til.

For å lette den første overgangen til, anbefales det å bruke alternativ 1 og flytte brukere til med anrop først. Dette gir brukerne tid til å gjøre seg kjent med den nye applikasjonen mens de fremdeles bruker den eksisterende lokale anropsplattformen. Når du er klar til å flytte brukere til, vil du konfigurere dem til å registrere seg på skyanropsplattformen.

For mer informasjon om disse to alternativene, se Migrasjonsreise - ett eller to trinn? .

For en fullstendig liste over støttede enheter for, se Støttede enheter for Webex Calling.

Bekreft enhetens kvalifisering

Som nevnt tidligere støtter den et delsett av Cisco IP-telefoner og krever en annen fastvaretype for telefonene i 7800 og 8800-serien. Unified CMtelefoner kjører Enterprise-firmware mens telefoner kjører multiplatform Phone (MPP) firmware. Det anbefales å kontrollere hvilke registrerte telefoner som er kvalifisert for oppgradering til MPP-fastvaren i forberedelsesfasen. Dette gir deg tid til å erstatte ikke-kvalifiserte telefoner med en av de støttede telefonmodellene eller til å identifisere en alternativ plan, som å flytte en bruker bare til Webex-appen.

For å hjelpe deg med å bestemme kvalifiseringen til telefonene, har Control Hub et innebygd verktøy som heter Migrere telefonen til Webex Calling. Når du bruker dette verktøyet til å kontrollere enhetens kvalifisering, velger du alternativet Overføring Generer bare enhetslisens.

Control Hub-verktøyalternativ for å bekrefte at Unified CM telefoner er kvalifisert for Webex Calling

Dette alternativet lar deg laste opp en CSV-fil som inneholder telefonene, slik at du kan sjekke kvalifiseringen til hver telefon. Ved å velge dette migreringsalternativet, legger det ikke telefonene til siden du fremdeles er i forberedelsesfasen og ikke er klar til å gjøre dette ennå. Hvis du vil ha mer informasjon, kan du se Overføre telefonen til Webex Calling.

Det er mulig at noen av telefonene kan komme tilbake med en ukjent kvalif isering. Dette er vanligvis fordi det ikke er mulig å validere noe informasjon om telefonen i back-end-systemet. For alle telefoner som har U kjent status, har du to alternativer for å bekrefte om de er kvalifisert for å oppgradere til MPP-fastvaren.

Kontroller hver telefon manuelt og bekreft modell- og maskinvareversjonen (PID VID)

7800/8800 telefonetikett med modell- og maskinvareversjonsinformasjon

Bruk Cisco IP-telefonberedskapsverktøyet

Last ned verktøyet fra https://github.com/joemar2/mpp_readiness_check.

Dette verktøyet er ikke et offisielt Cisco-verktøy og støttes heller ikke TAC. Den har best mulig støtte, men er gratis å bruke.

Dette verktøyet må kjøres på en maskin som er lokal og kan få tilgang til serverne og IP-telefonene. Den har et alternativ for å aktivere netttilgang på IP-telefonene, som anbefales og trengs for å få de beste resultatene. Derfor bør den brukes i fritiden for å unngå forstyrrelser for sluttbrukerne. Utgangen fra verktøyet gir en rapport som viser hvilke av telefonene i 7800- og 8800-serien som er kvalifisert for å oppgradere til MPP-firmware. Fordi den får direkte tilgang til telefonen, kan den bekrefte de ukjente enhetene som ble rapportert fra Control Hub-verktøyet.

Rapport om Cisco IP-telefonberedskapsverktøy

Brukere

En av de viktigste forberedelsene for å sikre at du har en vellykket migrering, er riktig brukerklargjøring. Du må planlegge riktig for alle brukere selv om du gjør en trinnvis migrering. Brukere må være klargjort for ett av følgende:

Distribuere med anrop

Implementere med

Konfigurere tjenester for en bruker

For å gjøre brukere søkbare i katalogen (klikk for å ringe, Brukerkontaktinformasjon, telefonkatalogsøk).

Det anbefales at du klargjør alle brukere før eller ved starten av prosjektet. Dette inkluderer brukere som fremdeles bruker Unified CM for sin anropsplattform som er uavhengig av anropende enhet (IP-telefon, Jabber,). Når brukere blir migrert til (og/eller), oppdaterer du lisensene deres for å aktivere tjenestene de trenger. Ved å klargjøre alle bedriftsoppringende brukere før du starter overgangen, lar den en bruker som har gått over til eller søke i katalogen etter en bedriftsanropende bruker som fremdeles er på Jabber og/eller på. Dette sikrer at overførte brukere kan finne andre brukeres kontaktinformasjon og ringe til dem ved hjelp av katalogoppslaget.

Figur katalogsøket viser et eksempel på en bruker som søker etter en annen bruker. Søkeresultatene viser brukerens kontaktinformasjon og kan være for en bruker som fremdeles er på Jabber og eller for en bruker som har gått over til og/eller.

Webex App katalogsøk

Deretter bestemmer du hvilke av de eksisterende lokale anropsbrukerne som skal overføres til. Hvis alle eller et stort antall brukere skal overføres, anbefales det å flytte brukere i grupper for å sikre at prosjektteam, IT-ansatte og støttepersonell er i stand til å håndtere overgangen og eventuelle problemer som kan oppstå. Du bør også avsette litt tid til å gi innledende informasjon og opplæringsøkter for å forberede brukerne på denne overgangen. Gruppering av bruker overganger kan gjøres basert på en rekke kriterier, inkludert plasseringen eller nettstedet brukerne er tilordnet, brukeravdelinger eller til og med brukertyper (kunnskapsarbeidere, ledere, mobile arbeidere og så videre).

For eksempel, hvis brukere i distribusjonen er delt på tre hovedområder, New York (NYC), San Francisco (SFC) og Research Triangle Park (RTP), kan en brukerovergangsplan se ut som planen skissert i Brukerovergangsplan for områdetabell.
Tabell 4. Brukerovergangsplan etter nettsted
Bruker nettsted/plassering Informasjon og opplæringsøkter før overgangen Overgangsperiode Støtte etter overgang
NYC (1 525 brukere) Uken 1. april 15. april — 27. april Uken 29. april
SFO (1.600 brukere) Uken 6. mai 20. mai — 31. mai Uken 3. juni
RTP (1 275 brukere) Uken 3. juni 17. juni — 28. juni Uken 1. juli

En annen viktig faktor er å overføre brukere sammen som har avhengigheter mellom hverandre . Dette kan omfatte, men er ikke begrenset til, følgende:

BLF-overvåking

Samme jaktpilot/gruppe

Del linjer

Del av samme samtalegruppe

Bruke de samme telefonnummerene

Intercom

Admin/Leder.

Du kan se gjennom konfigurasjonen (GUI eller eksport) eller bruke verktøyet Migration Insights til å identifisere brukergruppene med disse avhengighetene.

Tabell 4. Brukerovergangsplan etter nettsted
Bruker nettsted/plassering	Informasjon og opplæringsøkter før overgangen	Overgangsperiode	Støtte etter overgang
NYC (1 525 brukere)	Uken 1. april	15. april — 27. april	Uken 29. april
SFO (1.600 brukere)	Uken 6. mai	20. mai — 31. mai	Uken 3. juni
RTP (1 275 brukere)	Uken 3. juni	17. juni — 28. juni	Uken 1. juli

PSTN-tilkobling

kan få tilgang til PSTN på tre måter: Cisco-anropsplaner, Cloud connect for (tidligere Cloud Connected PSTN) og lokal PSTN (lokal gateway). En enkelt plassering som definert i kan imidlertid bare tilordnes til et enkelt PSTN-alternativ.

Lokalt PSTN med en lokal gateway (LGW) er en viktig komponent i overgangsstrategien. Det gir tilkobling mellom lokal distribusjon og/eller PSTN og plattformen. støtter både Cisco og sertifiserte tredjeparts sesjonsgrensekontroller (SBC) som kan brukes som lokal gateway. For den siste listen over støttede SBC-er, se Liste over støttede SB C-er.

støtter opptil 250 samtidige anrop fra en enkelt lokal gateway som er registreringsbasert og mer enn 250 samtidige anrop fra en enkelt lokal gateway som er sertifikatbasert. Sertifikatbaserte lokale gateways kan støtte opptil 6500 samtidige anrop, men dette er basert på typen tilkobling den lokale gatewayen må ha (Over-the-Top vs interconnect peering) og SBC-modellen den lokale gatewayen distribueres på. Disse grensene er i hovedsak standard tellegrense for både lokale gateway-baserte PSTN-anrop og mellomlokalitetsanrop mellom og endepunkter. Hvis du vil ha mer informasjon, kan du se Komme i gang med lokal gateway.

Alle anrop som overskrider denne grensen avvises med en 403 forbudt. Den aktive talekommandoen for visning av anrop kan kjøres på den lokale gatewayen når som helst for å bestemme det totale antall aktive anrop.

Dårlige nettverksforhold mellom en lokal gateway og aksess-SBC kan begrense ytelsen til signalforbindelsen, noe som fører til en enda lavere grense for samti dige anrop. Enveis ventetid mellom den lokale gatewayen og datasenteret bør ikke overstige 100 ms og jitter bør være mindre enn 10 ms mens pakketap er mindre enn 0,5%.

Funksjoner og funksjonsbruk

Når du vurderer gjeldende miljø, er det viktig å identifisere og gjennomgå hvilke funksjoner som er konfigurert. I tillegg er det viktig å forstå bruken av funksjonene slik at du kan (på nytt) definere forretningsmessige og tekniske krav til distribusjonen.

Analyser konfigurasjonen for å finne ut hvilke funksjoner som er konfigurert. Dette er alle statiske data som angis når en funksjon eller innstilling er konfigurert på systemet. Følgende alternativer kan brukes til å fullføre denne analysen:

Gjennomgå konfigurasjonen i admin GUI

konfigurasjonseksport - masseeksport eller AXL

verktøy for migreringsinnsikt (anbefalt)

Cisco tredjeparts partnerverktøy (Anbefalt).

For å analysere funksjonsutnyttelse effektivt, er det viktig å undersøke dynamiske systemdata som utnyttelse, registreringer og anrop saktivitet. Ulike analytiske verktøy og dashbord gir innsikt i disse beregningene, noe som muliggjør en omfattende forståelse av system ytelse og kapasitet, noe som støtter informert beslutningstaking under migrering og optimalisering. Følgende alternativer kan brukes til å fullføre denne typen analyse:

Gjennomgang av rå CDR-poster

Gjennomgang av Unified CM RTMT-data

Migration Insights verktøy ved hjelp av CDR-data

Gjennomgang av Cloud-koblet UC-analyse i

Anropsvolum

Registrerte endepunkter

(CAC) lokasjoner

Bagasjeromsutnyttelse.

Cisco tredjeparts partnerverktøy.

Cisco anbefaler at du starter med Webex Control Hub Migration Insights-verktøyet for denne analysen. Du importerer eksport.TAR-filen og Unified CM CDR-filene (valgfritt, men nødvendig for funksjonsut nyttelsesanalyse) til verktøyet. Verktøyet vil generere følgende CSV-baserte rapporter som kan brukes til å starte analysen:

Tabell 5. Rapporter generert fra Unified CM .tar-fil
Rapportnavn
Rapportbeskrivelse
ImportedDataBulk.csv
Alle brukere og enheter fra Unified CM data
DeviceEligibility.csv
Identifiserer enheter som er kvalifisert for migrering til Webex Calling (IP-telefoner, Room OS- enheter, ATA-er og tredjepart)
DevicePoolNumbers.txt
Liste over alle tall i en bestemt enhet spool
HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv
Detaljer om enheter og brukere som bør migreres sammen basert på delte linjer, jakt pilot, samtalekø, anropsparkering og samtaleopptakskonfigurasjon
HuntGroupMigrationInsight.csv
Detaljert informasjon om tildelte jakt linjer, linjegrupper og tilknyttede agenter
SharedlineGroupMigrationReport.csv
Oversikt over hvordan telefonnumre (katalognumre) deles mellom brukere

Tabell 6. Rapporter generert fra Unified CM .tar og CDR. gzip-filer
Rapportnavn
Rapportbeskrivelse
FeatureUsageBasedDeviceEligibilityReport.csv
Informasjon om kvalifisering for enhetsmigrering basert på funksjonsbruken
FeatureUsageWithLastUsageDateReport.csv
Brukstall for antall ganger jaktpilot (er) og anropskø (er) er blitt kalt sammen med siste bruks dato
UserWorkspaceLastUsage.csv
Siste bruksdato for brukere og arbeidsområder for både myke klienter og hardtelefoner
DIDUsageReport.csv
DID-bruk for både tildelte og ikke-tildelte DID-er

Hvis du vil ha mer informasjon om Migreringsinnsikt-rapportene, kan du se Over føringsin nsikt.

Hvis du trenger mer informasjon om funksjonene og bruken etter å ha gjennomgått informasjonen i Migration Insights-rapportene, anbefaler Cisco å vurdere et av Ciscos tredjepartsmigreringsverktøy for partnere og/eller å gjennomgå konfigurasjonene i GUI eller i konfigurasjonseksportdataene.

Tabell 5. Rapporter generert fra Unified CM .tar-fil
Rapportnavn Rapportbeskrivelse
ImportedDataBulk.csv Alle brukere og enheter fra Unified CM data
DeviceEligibility.csv Identifiserer enheter som er kvalifisert for migrering til Webex Calling (IP-telefoner, Room OS- enheter, ATA-er og tredjepart)
DevicePoolNumbers.txt Liste over alle tall i en bestemt enhet spool
HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv Detaljer om enheter og brukere som bør migreres sammen basert på delte linjer, jakt pilot, samtalekø, anropsparkering og samtaleopptakskonfigurasjon
HuntGroupMigrationInsight.csv Detaljert informasjon om tildelte jakt linjer, linjegrupper og tilknyttede agenter
SharedlineGroupMigrationReport.csv Oversikt over hvordan telefonnumre (katalognumre) deles mellom brukere

Tabell 6. Rapporter generert fra Unified CM .tar og CDR. gzip-filer
Rapportnavn Rapportbeskrivelse
FeatureUsageBasedDeviceEligibilityReport.csv Informasjon om kvalifisering for enhetsmigrering basert på funksjonsbruken
FeatureUsageWithLastUsageDateReport.csv Brukstall for antall ganger jaktpilot (er) og anropskø (er) er blitt kalt sammen med siste bruks dato
UserWorkspaceLastUsage.csv Siste bruksdato for brukere og arbeidsområder for både myke klienter og hardtelefoner
DIDUsageReport.csv DID-bruk for både tildelte og ikke-tildelte DID-er

Cisco-integrasjoner: Unity Connection UCCX UCCE

Talepost er en integrert del av tilbudet og er innebygd i løsningen. kan ikke integreres med en lokalbasert talepostløsning som Unity Connection eller Unity Connection Express. Videre er det ingen naturlig måte å migrere eksisterende Unity-tilkoblingstale postmeldinger eller hilsener til den opprinnelige taleposttjenesten som er tilgjengelig med. Noen av Ciscos tredjepartspartners migreringsverktøy har muligheter til å migrere noen av disse dataene. Hvis du vil ha mer informasjon om talepost for, kan du se Konfigurere og administrere innstillinger for talepost for en bruker. Webex Calling

støtter også delte talepost- og fakspostbokser. Hvis du vil ha mer informasjon, kan du se Administrer en delt talepost og innkommende faksboks for. Webex Calling

har en innebygd Auto Attendant-funksjon som er inkludert som en del av kjerneplattformen. Denne funksjonen tillater overgang av Unity Connections anropsbehandlere og automatisk ledsagerfunksjonalitet. Kontrollhub-verktøyet, Migrere funksjoner fraUnified CM, støtter migrering av Unity-tilkoblingskonfigurasjonene til Auto-Attendants. Hvis du vil ha mer informasjon om bruk av dette verktøyet, kan du se Migrering av enheter og funksjoner fra Unified CM tilWebex Calling.

Samtaleopptak

inkluderer to alternativer for samtaleopptak uten ekstra kostnad.

Webex anropsopptak

Dubber Go-opptak (partnertilbud) - en integrasjon mellom og dubber der alle innspilte medier holdes sikkert i skyen.

Inkludert opptaksalternati vtabell fremhever noen viktige funksjoner i de to samtale opptaksalternativene som er tilgjengelige uten ekstra kostnad.

Tabell 7. inkludert opptaksalternativer
Webex Double Go

Tilgjengelig for alle brukere Tilgjengelig for alle brukere

Ubegrensede opptak Ubegrensede opptak

1 års oppbevaringsperiode* 30-dagers oppbevaringsperiode

100 GB lagringsplass per organisasjon -

Compliance-ansvarlige kan få tilgang til og administrere anropsopptak -

API-er for å administrere opptak -

Administratorer kan konfigurere og administrere brukernes tilgang til sine anropsopptak
Brukere kan administrere sine egne opptak ved hjelp av User Hub og/eller Webex-appen.
Bare brukere kan få tilgang til og administrere opptakene sine
Fra dubberportalen deres.

Hvis organisasjonen din krever ekstra opptaksfunksjoner som samtale opptak, lengre oppbevaringsperioder, mer lagringsplass, AI-analyse og/eller administratortilgang, finnes det betalte tilbud eller tillegg fra både Cisco og tredjeparts opptaksleverandører. Hvis du vil ha mer informasjon om opptaksleverandører, konfigurasjoner og tilleggspartnertjenester, kan du se Administrer anro psopptak for Webex Calling.

Tabell 7. inkludert opptaksalternativer
Webex	Double Go
Tilgjengelig for alle brukere	Tilgjengelig for alle brukere
Ubegrensede opptak	Ubegrensede opptak
1 års oppbevaringsperiode*	30-dagers oppbevaringsperiode
100 GB lagringsplass per organisasjon	-
Compliance-ansvarlige kan få tilgang til og administrere anropsopptak	-
API-er for å administrere opptak	-
Administratorer kan konfigurere og administrere brukernes tilgang til sine anropsopptak Brukere kan administrere sine egne opptak ved hjelp av User Hub og/eller Webex-appen.	Bare brukere kan få tilgang til og administrere opptakene sine Fra dubberportalen deres.

Tredjepartsintegrasjoner

^{støtter en rekke tredjepartsintegrasjoner inkludert, men ikke begrenset til, SBC-er
for lokale gateways, IP-telefoner, intercom-telefoner, høyttaler/personsøkere, ATA, etc.} I tillegg til disse tredjepart ^sen hetene Webex Calling støtter den forskjellige tredje ^part sløsninger for kundesupport, analyse, opptak, fakturering osv. Hvis du vil ha mer informasjon om ^tredjepart sløsninger, kan du se Webex App Hub.

Planlegg

Prosjektplan på høyt nivå

Migrasjonsreise - ett eller to trinn?

Alternativ 1: Enkelt trinnvis brukermigrering

Alternativ 2: Dobbeltrinns brukermigrering

Trinn 1

Trinn 2

Prosjektplan på høyt nivå

Når du utvikler en prosjektplan på høyt nivå for migrering fra til, er det viktig å etablere klare faser og milepæler som samsvarer med både forretning smål og tekniske krav. Planen bør begynne med en omfattende vurderings fase, inkludert å samle detaljerte tekniske og forretningsmessige krav, samt identifisere interessenter og definere suksesskriterier. Viktige hensyn inkluderer ressursal lokering, tidslinjeestimering, risikostyring, og kommunikasjonsstrategier for å sikre at alle parter blir informert og engasjert gjennom hele migreringen. I tillegg bør planen inkludere valideringskontrollpunkter som pilottesting og trinnvise utrullinger for å minimere forstyrrelser og tillate justeringer basert på tilbakemelding.

Eksempler på elementer som skal inkluderes i prosjektplanen er:

Definere omfanget av migrering (f.eks. hvilke brukere, enheter og funksjoner som skal overgå)

Planlegge opplæringsøkter for sluttbrukere og støtteteam

koordinere vurderinger av nettverksberedskap, og

Planlegging for cutover-aktiviteter med fallback-alternativer. Det er også viktig å integrere overholdelses- og sikkerhetsvurderinger, samt støtte- og optimaliserings faser etter migrering.

Ved å strukturere prosjektplanen med disse hensynene, kan organisasjoner bedre håndtere kompleksitet, redusere risiko og oppnå en jevnere overgang til.

Migrasjonsreise - ett eller to trinn?

krever at brukerne bruker den myke klienten for å ringe. Derfor, hvis noen brukere fortsatt bruker, har du to alternativer på når du kan flytte dem til. Du kan enten utføre en brukeroverføring i ett trinn eller en totrinnsmigrering av brukere.

Alternativ 1: Enkelt trinnvis brukermigrering

I en enkelt trinnvis migrering går brukerne over fra til samtidig som de blir overført fra Unified CM til. Dette alternativet er vanligvis for kunder med et lite antall brukere å migrere, og kan administrere å flytte både brukerens myke klient og ringetjeneste til samtidig. Figuren Brukerens anropstjeneste, myk klient og telefon migrerer til samtidig nedenfor viser denne typen migrering. Med dette alternativet vil en bruker ha følgende fullført samtidig:

Anropstjenester flyttet fra til

Telefonnumre og utvidelser flyttet fra til

Myk klient gikk over fra Jabber til - vil registrere seg til

Telefonregistrering flyttet fra til.

Brukerens ringetjeneste, myk klient og telefon migrerer til samtidig

Dette kan fortsatt være en trinnvis migrering der grupper av brukere flyttes til forskjellige tidspunkter, men når hver bruker flyttes, skjer alle disse samtidig.

Alternativ 2: Dobbeltrinns brukermigrering

Den andre tilnærmingen er en totrinnsmigrasjon. I trinn 1 blir brukere overført fra til, men fortsetter å ringe tjenester. Deretter flyttes brukerne i trinn 2 fra Unified CM til. Dette alternativet anbefales for større kunder for å administrere sluttbrukerendringene og ønsker å skille brukerens myke klientendring fra endringen av anropstjenesten. Følgende figur Overfør myk klient; deretter migrere samtaletjeneste, myk klient og telefon til Webex Calling nedenfor fremhever denne typen migrering.

Trinn 1

Myk klient overgått fra til - vil registrere seg til.

Trinn 2

Anropstjenester flyttet fra til.

Telefonnumre og utvidelser flyttet fra til.

registreringen flyttet fra til.

Telefonregistrering flyttet fra til.

Migrere myk klient; deretter migrere anropstjeneste, myk klient og telefon til Webex Calling

Dette kan fortsatt være en trinnvis migrering der grupper av brukere flyttes til forskjellige tidspunkter i begge trinnene.

Alternativet du velger avhenger av hvordan du vil administrere brukernes overgang til og. Anbefalingen er å ta det i trinn (alternativ 2). Dette lar deg minimere slutt brukerens endringer på en gang og dele innsatsen opp på forskjellige deler av prosjektet. Men hvis du foretrekker å ha brukere bare påvirket én gang, er bruk av alternativ 1 også gyldig.

Når du ser på den anbefalte reisen (alternativ 1), viser overgangsk artfiguren Jabber til Webex App på høyt nivå nedenfor overgangen på høyt nivå for trinn 1.

Jabber til Webex App overgangskart på høyt nivå

I dette trinnet blir brukere overgått fra Jabber til for alle sine samtaletjenester. Imidlertid er anropsplattformen fortsatt Unified CM og vil registrere sine samtaletjenester til. Som vist i overgangskartet på høyt nivå fra Jabber til Webex App endres ikke den lokale infrastrukturen, og fungerer på samme måte som Jabber gjør. Den eneste endringen er at det krever en tilkobling ut til.

Hvis du vil ha mer informasjon om denne overgangen, kan du se Jabber til Webex overgangskart og distribusjonsveil edning under Klient-delen på siden Samarbeidsovergang.

Unified CMtil over Webex Calling gangskart figur på høyt nivå er over gangen på høyt nivå fra til. Dette er trinn 2 av den anbefalte reisen.

Unified CMtil overgang Webex Calling skart på høyt nivå

Hvis du bestemmer deg for å bruke enkelttrinnsmetoden, gjelder dette også.

I dette trinnet blir brukere overført til i grupper. På dette tidspunktet begynner brukerne å bruke for sine samtaletjenester, anropsregistrering og IP-telefonregistrering.

Siden brukere beveger seg i grupper, vil Enterprise-brukere bli delt mellom de to anrops plattformene under overgangen. Fase 1 inn Unified CMtil over Webex Calling gangskartfigur på høyt nivå viser denne tilstanden. I løpet av denne fasen er det nødvendig med planlegging for hvordan man administrerer samtaler mellom brukere på de to plattformene og hvordan PSTN-anrop vil bli rutet. Hver gang en gruppe brukere blir overført til, kreves det oppdateringer for oppringingsplaner og samtaleruting på, og den lokale gatewayen (e).

Når alle brukere, myke klienter og enheter er overført til (fase 2), kan all lokal UC-infrastruktur fjernes og tas ut av drift.

Utforming

Regionvalg

Steder

PSTN

Oppringingsplan

Lokal oppringingsplan i

oppringingsplan

Opptak

1. Valg av leverandør av samtaleopptak

2. Regionvalg

Nødanrop

Lisensiering

Manuell tildeling gjennom

Automatiske lisenstildelingsmaler

Massetildeling gjennom CSV-mal

API-basert oppgave

Lisenskrav

Brukerklargjøring

Brukergrupper

Anbefalt tilnærming når du migrerer fra til

Utforming av brukergrupper

Enkel pålogging (SSO)

Støtte for flere IdP

1. Fusjoner og oppkjøp

2. Flere uavhengige IT-avdelinger

3. Ulike brukergrupper eller domener

4. Støtte for ulike autentiseringsprotokoller

5. Forbedret sikkerhet og samsvar

6. Forenklet brukeropplevelse

Duo MFA med SSO for

Funksjoner

Automatisk ledsager

Ring Park

Henting av anrop

Anropskø

Jaktgruppe

Driftsmoduser

Personsøkingsgruppe

Opptak

Enkeltnummerrekkevidde

Talepostgruppe

Regionvalg

er tilgjengelig globalt og leveres fra redundante datasentre i flere regioner: USA (Dallas, Chicago), Canada (Vancouver, Toronto), Europa (Frankfurt, Amsterdam), Storbritannia (London, Manchester), Australia (Melbourne, Sydney), Japan (Tokyo, Osaka), Saudi-Arabia (Riyadh, Jeddah) og India (Mumbai, Chennai). Medie-POP-ene tilbyr medietjenester for å optimalisere medienes rundturtider. Singapore-datasenteret brukes for eksempel til å optimalisere media tur- returtider for kunder i asiatiske land der tur-returtidene til enten Australia eller Japan- regionen kan være suboptimale. Datasentrene er sammenkoblet av en multi-gigabit og fullt redundant ryggrad. Figuren globalt distribuerte datasentre viser en oversikt over alle datasentre. For den siste listen over tilgjengelige datasentre, se Datasenterlokasjoner for Webex Calling.

Globalt distribuerte datasentre

Hver kunde er klargjort på en av forekomstene. All klargjøringsinformasjon for den kunden lagres i den forekomsten, og SIP-signaleringen for alle endepunkter og lokale gateways som er klargjort for den kunden, er knyttet til forekomsten kunden er klargjort på. Fordi det er vanskelig å endre det første regionvalget, er det viktig å vurdere alle relevante faktorer som en del av beslutnings prosessen som fører til regionvalg. For å unngå overdreven signalering rundtursforsinkelse, er det viktig å bestemme tidlig i overgangsprosessen hvilken forekomst som skal brukes. Cisco anbefaler å velge forekomst som gir de laveste signaleringstidene for det største antallet brukere i distribusjonen.

For tilgjengelighet i land, se Hvor er Webex tilgjengelig? .

Steder

For å forberede klargjøring av lokasjoner, må den nødvendige informasjonen for alle overføringssteder samles inn. Informasjonen som trengs for hvert sted er oppsummert i Informasjon som skal fanges for hvert sted.
Tabell 1. Informasjon som skal innhentes for hvert sted
Informasjon Kommentar
Utvidelsesområde (er) Hvert sted i kan ha utvidelser som starter med forskjellige sifre. Ett siffer må spares for styr ingssifferet mellom lokalene (for eksempel 8) og ett for PSTN- styresifferet (for eksempel 9). Ingen utvidelsesområde kan starte med noen av disse to sifrene.
Alle utvidelsesområder på alle steder må være like lange.
DID-område (er) -
PSTN styringssiffer -
Nettstedskode Alle nettstedskoder for alle steder må være unike og ha samme lengde.
Hovednummer Når du oppretter et sted, må to DID-er klargjøres. Ett som hovednummer (for eksempel for å tilordnes en automatisk svartjeneste) og ett for telefonsvar erportalen.
Bestem en DID for telefonsvarernummeret.
Talepostnummer
Antall lisenser Nødvendige lisenser etter type inkludert Standard, Professional, Workspace, Ruteliste, Utgående anropsplan.
Samtidige samtaler i den travle timen Summen av samtidige samtaler mellom enheter og mellom enheter og den lokale gatewayen (PSTN og anrop til enheter). Nødvendig for å bestemme den nødvendige båndbredden til internettilgang.
Land -
Tidssone -
Språk -
Kontakt (Navn, Telefon, E-post) -
Adresse (Gateadresse, by, stat, postnummer) -
Nødetjenestens fysiske utsendelsessted for endepunkter Enhetsforsendelsessted som brukes til nødanrop inkluderer vanligvis følgende: bygningsadresse, bygningsadresse + etasjenummer, bygningsadresse+ suitenummer eller bygningsadresse + etasjenummer+kontor/kubisk nummer.
Per enhet unik fysisk nettverksplassering for nødetjenester Fysisk nettverksplassering for nødanrop inkluderer vanligvis følgende: svitsj/bryterport for kablede enheter, BSSID-er (Basic Service Set Identifiers) for trådløst tilkoblede enheter og/eller lokale IP-delnett (er) for endepunktsenheter.

PSTN

Når kundene designer en distribusjon, har kundene tre primære PSTN-tilkoblingsalternativer: Cisco C alling Plans (en skylevert PSTN-tjeneste administrert av Cisco), Cloud Connec ted PSTN-leverandører (CCPP, der leverandører leverer PSTN-tjeneste gjennom skyen) og lokal PSTN (der lokale gateways kobler bedriftsnettverket til PSTN). Med introduksjonen av PSTN-trunking for hybriddistribusjoner (for mer informasjon, se PSTN-trunking for hybriddistribusjoner ved PSTN-trunking), Webex Calling får organisasjoner ekstra fleksibilitet i migreringstilnærmingen. Denne funksjonen gjør det mulig for kunder å flytte PSTN til CCPP ved starten av overgangs reisen og begynne å gå over til skybasert PSTN for brukere, samtidig som de utnytter CCPP for å opprettholde PSTN-tjenesten for brukere som forblir på Cisco under en trinnvis migrering.

Denne hybride tilnærmingen gjør det mulig for organisasjoner å flytte utvalgte brukergrupper til skyen først, uten å umiddelbart revidere hele telefonimiljøet. Det introduserer imidlertid ytterligere kompleksitet og risiko, spesielt rundt tilpasning av eksisterende samtalerutingslogikk for å støtte den nye arkitekturen. Interoperabilitet med eldre applikasjoner, for eksempel faksservere, kontaktsentre eller personsøkings systemer, krever også nøye vurdering. Viktige tekniske utfordringer kan omfatte å sikre sømløs ende-til-ende-kodeforhandling og DTMF-signalering (Dual-Tone Multi-Frequency) på tvers av det blandede miljøet, samt validering av kompatibilitet med spesialiserte telefonfunksjoner. Rik tig planlegging og testing er avgjørende for å minimere forstyrrelser og opprettholde pålitelige taletjenester gjennom hele migreringsprosessen. I tillegg er kommersielle hensyn viktige, ettersom hybrid trunking krever en bruks lisens som er basert på antall samtidige anrop mellom det lokale miljøet og Cloud Connected PSTN Provider (CCPP).

Alternativt kan organisasjoner velge å beholde sin lokale PSTN-tilkobling gjennom hele overgangsfasen. I dette scenariet kan migrering til CCPP utføres på to måter: som en enkelt, koordinert cutover for alle brukere og steder når overføringen er fullført, eller trinnvis, med PSTN-migrering som skjer per sted når brukerne flyttes til. Denne tilnærmingen kan bidra til å effektivisere sameksistens og opprettholde kontinuitet for eldre integrasjoner, men den introduserer flere operasjonelle kompleksiteter. Blant disse er utfordringer knyttet til nummerportering, slik som behovet for presis koordinering av antall portordrer, potensielle forsinkelser, og leverandørpålagte begrensninger som et tak på antall samtidige portforespørsler eller begrensninger på portering av delsett av store antall blokker. Organisasjoner må nøye planlegge sin PSTN-overgangsstrategi, ta hensyn til disse logistiske hensynene for å unngå tjenesteavbrudd og sikre en jevn migreringsopplevelse.

Overføring til CCCP i starten kontra å beholde lokalt PSTN

Figuren Migrering til CCCP i starten kontra å beholde lokalt PSTN viser de to PSTN-overføring salternativene som er forklart ovenfor. Illustrasjonen til venstre viser scenariet der alle lokale brukere og programmer bruker Cloud Connec ted PSTN-tjenester gjennom en lokal koffert og en lokal gateway som ko bler den lokale gatewayen til, mens illustrasjonen til høyre viser scenariet der eksisterende lokale PSTN forblir på plass og brukere bruker lokal PSTN gjennom den lokale gateway-tilkoblingen mellom Webex Calling lokale enheter og. Under overgangen kan plasseringer byttes til å bruke Cloud Connected PSTN.

I begge scenariene bruker samtaler mellom lokal og bruker den lokale gateway-tilkoblingen. Forbindelsen mellom lokalt og må utformes og dimensjoneres tilsvarende basert på forventet antall samtidige samtaler og nødvendig redundans.

Oppringingsplan

For å oppnå sømløs interoperabilitet mellom og i løpet av migreringsperioden, må en omfattende nummerplanarkitektur utvikl es og implementeres på tvers av begge plattformene. Denne utformingen av nummerplanen med to plattformer sikrer konsekvent samtaler uting, nummeroversettelse, og funksjonens gjennomsiktighet, slik at brukere på begge systemene kan kommunisere uten tjenesteforringelse eller forstyrrelser i brukeropplevelsen gjennom sameksistensfasen.

Lokal nummerplan i

Under overgangen for å tillate sameksistens av enheter som er registrert på Unified CM og på bedriften, må nummerplanen endres slik at minst følgende krav kan oppfylles:

+E.164 ringer fra til

Utvidelsesoppringing fra til (internt på stedet, men også mellom steder hvis utvidelsesområdene er unike)

Forkortet oppringing mellom nettsteder fra til

Tvunget oppringing på nettet fra til

Tilbakringning fra katalogen for ubesvarte anrop til destinasjoner på

PSTN-anrop fra til PSTN hvis det brukes lokalt PSTN under overgangen

PSTN-anrop fra til hvis under overgangen PSTN-trunking for hybriddistribusjoner brukes til å gi PSTN-tilgang til lokale brukere gjennom Cloud Connect for

Tvunget på nettet fra til

Utvidelsesoppringing fra til (mellom nettsteder).

Hvis noen av de ovennevnte ikke støttes oppringingsvaner før overgangen, for eksempel ikke eksisterer noen forkortet innringingsvane mellom steder, trenger de ikke nødvendigvis å innføres under overgangen.

Figur Oppringings planen for beste praksis viser fremgangsmåten for oppringingsplan som beskrevet i Preferred Architecture for Cisco Collaboration 12.x Enterprise On-Premises Deployments, CVD. Viktige egenskaper ved denne tilnærmingen inkluderer:

Enkel partisjon for+E.164 katalognumre

Kjerneruting basert på+E.164 rutemønstre

Normalisering av alle oppringingsvaner til+E.164 ved hjelp av oversettelsesmønstre

Bruk av oversettelsesmønster som kaller søkeromsarv (alternativ Bruk opphavsmannens anro pssøkeområde angitt på oversettelsesmønstre).

Oppringingsplan for beste praksis

For eksempel vil PSTN-oppringing (9+1+10D) fra en enhet i SJC som er utstyrt med linjeanropssø keområde SJCinternational først bli matchet av 9.1 [2-9] XX [2-9] XXXXXX-oversettelsesmønsteret som normaliserer det oppringte partnummeret til +E.164. Det sekundære oppslaget bruker deretter det samme anropssøkeområdet SJCinternational igjen (anrop av søkeromsarv) og +E.164-sifrede strengen vil enten bli matchet av et +E.164 katalognummer i DN-partisjonen eller av et av PST N- rutemønstrene i USPSTNNational- eller SJCPSTNLocal-partisjonen. Forkortede samtalevaner innenfor og mellom steder implementeres av oversettelsene i ESN- og SJCTO E 164-partisjonen. Mens ESN- partisjonen er en global partisjon (tilgjengelig for telefoner på alle steder), er SJCTOE16 4-partisjonen bare tilgjengelig for brukere på stedet SJC. Dette forutsetter overlappende utvidelsesområder.

Det første trinnet for å aktivere anrop fra til er å sørge for at +E.164-destinasjoner blir rutet tilsvarende. Dette kan oppnås ved å legge til en skillevegg til nummerplanen, legge til +E.164 rutemønstre for alle destinasjoner til denne partisjonen, og til slutt legge partisjonen til alle anropende søkerom som representerer tjenesteklasser som må kunne nås. Oppretting av en dedikert partisjon er nødvendig for å muliggjøre opprettelse av en differensiert tjenesteklasse for samtaler som stammer fra. For å unngå anropsløyfer bør det innkommende anropssøkeområdet på bagasjerommet fra den lokale gatewayen ikke ha tilgang til partisjonen.

+E.164 ruting til Webex Calling

Som vist i fig. +E.164 ruting tilWebex Calling, for å muliggjøre ruting fra til for et sted med +E.164 DID-område +1 221 555 2XXX og stedskode 121, må et presserende rutem ønster som samsvarer med dette +E.164-området legges til partisjonen.

Hvis det ikke kreves et stedsspesifikt valg av lokal gateway, kan det i stedet for å bruke en ruteliste med en lokal rutegruppe som mål for rutemønstre som peker på en enkelt rutegruppe klargjøres med den lokale gatewayen som eneste medlem, og deretter peker rutemønstrene på en enkelt ruteliste med denne ene rutegruppen som eneste oppføring.

For å muliggjøre forkortet oppringing mellom steder til stedet blir det nødvendige rutemønster 8121.2XXX lagt til partisjonen. For områder som skal overføres til et oppringingsnormaliseringsmønster 8121.2XXX som normaliserer ESN-oppringing til +E. 164, kan det allerede finnes i ESN-partisjonen. I dette tilfelle synes 8121,2XXX å være overflødig, men så snart alle DNer i den respektive lokalisering er blitt migrert over til 8121,2XXX oppringingsnormaliseringsmønsteret kan fjernes, og deretter muliggjør rutemønsteret 8121,2XXX ESN-oppringing selv for utvidelsesbrukere i det området.

Med disse oppringingsplanendringer kan anrop til stedet plasseres ikke bare ved å ringe forkortet inter-site og +E.164. Internasjonal og nasjonal PSTN-oppringing er også mulig fordi disse oppringingsvanene først blir normalisert til +E.164 gjennom de allerede eksisterende translasjonsmønstre for oppringingsnormalisering og deretter blir rutet til ved å matche rutemønsteret +E.164 i partisjonen.

+E.164-rutemønstersamsvarende på stedets DID-område kan klargjøres mens alle DID-er fremdeles er vert på. Den beste matchende mønstertilpasningsalgoritmen sørger for at når et nummer som er hostet på blir oppringt, så er +E.164-katalognummeret som er klargjort på, et bedre samsvar enn rutemønsteret +E.164 med jokertegn som peker på, slik at samtalene blir utvidet til en linje på og ikke sendt til.

oppringingsplan

Hver bruker i er utstyrt med en utvidelse og/eller et+E.164 telefonnummer. Utvidelseslengden er en fast global innstilling: alle utvidelser i en distribusjon har samme lengde. Utvidelsesoppringing kan brukes mellom brukere både innenfor et sted og mellom steder. Forkortet utvidelsesoppr inging mellom nettsteder (sistnevnte tilfelle) fungerer bare hvis den oppringte utvidelsen er unik.

Hvis forkortet oppringing mellom steder er et krav, men det er overlapp mellom utvidelser som er tildelt på forskjellige steder, må det opprettes en bedriftsspesifikk nummereringsplan ved å prefikse utvidelsene med en tilgangskode, en områdekode. Hvis du vil ha mer informasjon, kan du se Foretrukket arkitektur for Cisco Collaboration 15 Lokale distribusjoner, Designoversikt tilgjengelig på Ciscos foretrukne arkitekturer for samarbeid.

Utvidelseslengden, oppringingingsvirkemåten mellom lokaliseringsutvidelsene, prefikslengden for oppringing mellom lokaliseringene og styresifferet i rutingprefikset for interlokasjonsoppringing er konfigurert i innstillingene for anropstjenesten i:

Prefiksl@@ engde for posisjonsrut ing: Prefikslengde inkludert styresifret. Kreves bare hvis en bedriftsnummerplan må etableres som alternativ forkortet foretaksoppringingsvane mellom lokaliseringer.

Styresiffer i rutingprefiks: Styresiffer for forkortet foretaksoppringingsvane mellom lokaliseringer. Overlapping med første siffer på et hvilket som helst sted og sted utgående nummersiffer bør unngås. Kreves bare hvis en bedriftsnummerplan må etableres som alternativ forkortet foretaksoppringingsvane mellom lokaliseringer.

Intern forlengelseslengde: Standard lengde på forlengelser. Kan være en hvilken som helst verdi mellom to og ti.
Når en lokal anropsstyring krever telefonoppringing eller oppringing ved hjelp av betydelige foretaksnumre (styringskode, områdekode, utvidelse) fra en lokal anropskontroll til og den lokale anropskontrollen sender en utvidelse som anrops-ID, må du også angi parameteren Maksimal ukjent utvidelseslengde i delen Anropsruting mellom og lokaler for å sikre at oppstrøms anrop fra den lokale anropskon trollen til kan klassifiseres som lokale anrop på riktig måte.

Tillat utvidelsesoppringing mellom steder: By tt for å aktivere/deaktivere utvidelsesoppringing mellom steder. Dette alternativet skal bare aktiveres hvis alle utvidelser i organisasjonen er unike. Hvis alternativet er deaktivert, må bedriftssignifik ante tall (styringskode, områdekode, utvidelse) eller telefonnumre ringes mellom steder.

De tre første parametrene brukes hovedsakelig til å bygge en oppringingsplan for telefoner for å minimere mellom sifrede tidsavbrudd når du bruker off-hook oppringing. Avvik fra disse globale innstillingene er fortsatt mulig (Eksempel - utvidelser med en annen lengde kan klargjøres), men en advarsel vises i Control Hub, og oppringing fra telefoner kan kreve blokkert oppringing for å unngå konflikter i den for håndsinnlastede nummerplanen.

Tabellen Enterprise-nummerering seksempel viser et eksempel på tre steder der ut videlsesområdene til to steder, NYC og RTP, er identiske. Etablering av et bedri ftsnummereringsskjema med styringssiffer 8 mellom steder, etterfulgt av en tresifret nettstedskode, og den firesifrede utvidelsen skaper en ikke-overlappende forkortet oppringingsvane mellom nettsteder.

Tabell 2. Eksempel på bedriftsnummerering
Nettstedet Utvidelsesområde Nettstedskode Enterprise-utvalg

NYC 2XXX 202 8 202 2XXX

SFO 3XXX 203 8 203 3XXX

RTP 2XXX 204 8 204 2XXX

For å muliggjøre en jevn overgang bør settet med oppringingsvaner for brukere før og etter overgang til ideelt sett være det samme. For å forberede overgangen for hvert sted må DID-områdene og utvidelsesområdene (eller forkortede samtalevaner på stedet) dokumenteres. Bas ert på denne informasjonen, må styringssifferet mellom steder velges.

Tabellen F aste lengdeforlengelsesområder viser et eksempel på tre steder og forlengelses områder med fast lengde. Fordi overlappende oppringingsvaner må unngås, er det viktig å sørge for at det første sifferet i rekkevidden ikke stemmer overens med styresifferet for forkortet oppringing mellom steder for et hvilket som helst utvidelsesområde. Hvis for eksempel 8 er valgt som styringssiffer for oppringing mellom steder, da kan ingen utvidelsesområde på noe sted starte med 8. Vanligvis samsvarer utvidelsene på et gitt sted med de siste sifrene i DID-ene som er tildelt det stedet. For å unngå konflikter kan det første sifferet i utvidelsen endres. Hvis for eksempel DID-er i +1 408 555 8XXX-området brukes på et sted, kan 7XXX i stedet for å bruke 8XXX som utvidelsesområde brukes for utvidelsene på det området

Tabell 3. Faste lengdeforlengelsesområder
Nettstedet Utvidelsesområde Utvidelser Nettstedskode Enterprise-utvalg

NYC 2XXX 2XXX 202 8 202 2XXX

SFO 8XXX 7XXX 203 8 203 7XXX

RTP 1XX 11XX 204 8 204 11XX

Syvsifrede oppringingsstrenger som er oppringt på en enhet som bruker den amerikanske nummerplanen, overlapper med et syv-sifret mønster for lokal oppringing i den forhåndsinnlastede amerikanske nummerplanen. For å unngå overlapping mellom oppringingsvaner på nett og utenfor nettet (PSTN), kan en obligatorisk ekstern tilgangskode brukes på det stedet. Hvis det eksisterende bedriftsnummereringsskjemaet og den tilsvarende forkortede innbyrdes oppringing overlapper med mønstre i den nasjonale nummereringen, kan det under overgangen til nummereringsskjemaet for å unngå overlapping også endres til en lengre eller kortere form. Den enkleste måten å oppnå dette på er å legge til et ekstra polstringssiffer i nummereringsskjemaet. Det nye lengre oppringingsskjemaet mellom nettsteder trenger bare å bli tatt i bruk av brukere som allerede er migrert til. Brukere som fortsatt er på, kan fortsette å ringe syv sifre. Bedriftsoppringingsplanen på må i dette tilfellet sørge for at forkortet syvsifret oppringing fra Unified CM til blir omgjort til enten +E.164 eller til det forkortede oppringingsformatet som er distribuert på. Dette må gjøres før du sender anropet til den lokale gatewayen.

Table Transitioning syv-sifret oppringing viser et eksempel på denne omnummereringen. I dette eksemplet bruker forkortet innbyrdes oppringing på styringssiffer 8 etterfulgt av en tosifret nettstedskode og en firesifret utvidelse. For å unngå syv-sifret forkortet innbyrdes oppringing for steder på, kan stedskodene lett endres til tre sifre ved å prefiksere et vilkårlig utfyllingssi ffer (8 i eksemplet) til de tosifrede stedskodene som brukes i, slik at oppringing mellom steder fra telefoner bruker styringssiffer 8 etterfulgt av polstringsifferet 8, den gamle tosifrede stedskode og den firesifrede forlengelse. Brukere på trenger ikke å huske nye nettstedskoder; de trenger bare å huske å bruke 88 som prefiks for oppringing mellom nettsteder i stedet for 8 på.

Tabell 4. Overgang av syv-sifret oppringing

Nettstedet Utvidelser Nettstedskode Enterprise-utvalg 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 scenario med forskjellige virksomhetsnummerformater på, og hvis bedriftsnumre presenteres som informasjon om anropende part for samtaler fra til (for eksempel - Anrop fra enheter uten DID), er det viktig å også implementere en kartlegging mellom de forskjellige nummerformatene for informasjon om oppringende part for å sikre at tilbakeringing fungerer. Denne kartleggingen kan oppnås ved å bruke anropspartens transformasjonsmønster på stammen mellom og den lokale porten.

Opptak

En velutviklet løsning for samtaleopptak krever nøye vurdering av flere viktige designelementer for å sikre at den stemmer overens med organisatoriske mål, regulatoriske krav og tekniske begrensninger. To av de mest kritiske beslutningene involverer valg av leverandør og regionvalg, som begge må skreddersys globalt og overstyres på bestemte steder, basert på forretningsbehov.

1. Valg av leverandør av samtaleopptak

Å velge riktig leverandør av samtaleopptak er grunnleggende for å oppfylle forretning smål og sikre funksjonstilpasning på tvers av organisasjonen:

Globalt leverandørvalg: Organisasjoner utpeker vanligvis en primær leverandør av samtale opptak på globalt nivå, noe som sikrer konsistens i funksjonssett, samsvar og støtte på tvers av alle lokasjoner

Stedsbaserte overstyringer: I scenarier der bestemte områder eller regioner har unike forretningsbehov eller forskriftskrav, kan det være nødvendig å overstyre det globale leverandørvalget og spesifisere alternative leverandører for disse stedene. Denne fleksibiliteten støtter varierende overholdelsesmandater og lokale operasjonelle behov

Forretningskrav: Valget av leverandør bør drives av en vurdering av virksomhetsdrivere som overholdelse av forskrifter (eksempel - MiFID II, HIPAA), kvalitetssikring, tvisteløsning eller opplæringsbehov

Tilgjengelighet av funksjoner: Leverandører bør evalueres basert på deres evne til å levere nødvendige funksjoner, for eksempel sanntidsovervåking, søke- og avspillingsfunksjoner, kryptering, oppbevaringspolicyer, integrering med analyseplattformer og støtte for forskjellige samtaletyper (innkommende, utgående, interne).

2. Regionvalg

Det er avgjørende for samsvar og ytelse å bestemme regionen der anropsopptak lagres og behandles:

Globalt regionvalg: Som standard kan organisasjoner velge en enkelt region for lagring av anropsopptak for å forenkle administrasjon og styring

Stedsbaserte regionoverstyringer: Når lover om dataopphold eller bedriftspolicyer krever det, kan det være nødvendig å overstyre den globale regioninnstillingen for bestemte steder, og sikre at anropsopptak lagres og behandles innenfor de nødvendige geografiske grensene

K@@ rav til dataopphold: Utformingen må ta hensyn til internasjonale og lokale databeskyttelsesforskrifter (for eksempel GDPR, CCPA eller landsspesifikke mandater) som kan diktere hvor og hvordan samtaleopptak oppbevares.

Et annet kritisk aspekt som skal tas opp under planleggingen og utformingen av en anropsopp taksløsning for, er estimering av lagringsbehov. Det er viktig å forutsi lagringsbehov nøyaktig for å sikre at tilstrekkelig kapasitet er tilgjengelig for å støtte pågående forretnings drift, opprettholde samsvar og unngå tjenesteforstyrrelser.

Flere viktige parametere bør vurderes når du bestemmer forventet lagringsbehov:

Volum av innspilte samtaler: Vurder det forventede antallet samtaler som vil bli tatt opp innen et gitt tidsintervall (f.eks. per dag, uke eller måned). Dette inkluderer ikke bare eksterne samtaler, men også intern kommunikasjon, hvis det kreves av forretningspolitikk eller regulatoriske mandater

Gjennomsnittlig samtalevarighet: Beregn den typiske lengden på innspilte samtaler, ettersom lengre samtaler vil forbruke mer lagringsplass. Variasjoner i samtalens varighet på tvers av ulike avdelinger eller brukergrupper bør også tas med i estimatet

Oppbevaringsperiode: Definer hvor lenge opptakene må beholdes, noe som ofte er diktert av organisasjonspolitikk eller eksterne forskrifter (for eksempel bransjespesifikke samsvarsstandarder). Lengre oppbevaringsperioder vil øke det totale lagringskravet

Vekstanslag: Vurder forventet vekst i samtalevolum eller utvidelse av registreringsomfanget, som kan skyldes virksomhetsskalering, nye regulatoriske krav eller introduksjon av flere brukere eller lokasjoner.

Ved å analysere disse parametrene grundig, kan organisasjoner utvikle en robust lagringsstrategi som sikrer skalerbarhet, kostnadseffektivitet og overholdelse av forskrifter for samtaleopptaksløsningen. Det anbefales også å regelmessig gjennomgå og justere lagringstildelinger etter hvert som bruksmønstrene utvikler seg over tid.

Nødanrop

Kravet om å dirigere et nødanrop til det aktuelle utsendelsessenteret er et krav for enhver anropstjeneste som tilbyr PSTN-tjeneste. Med er rutingen av nødanrop hjemmehørende i løsningen og inkluderer støtte for alle nasjonale nødnumre i landene som støtter. Rutingen av et nødanrop inn er basert på plasseringen som er definert innenfor og PSTN-tilgangsmetoden for lokasjonen. Nødnumrene i er forhåndsdefinerte og spesifikke for landet brukerne og enhetene er distribuert i.

Det er to metoder for å levere nødanrop. Det er en grunnleggende rutetjeneste for nødanrop og en forbedret rutetjeneste for nødanrop. Den grunnleggende rutetjenesten for nødanrop vil bruke et administratorvalgt nummer for å identifisere plasseringen og anropsruten for å nå nødetatene. For grunnleggende nødanrop er anropsbanen vanligvis gjennom kundens PSTN-alternativ for det stedet. har også forbedret ruting av nødanrop designet for distribusjoner i USA og Canada som har forskriftskrav som krever bruk av en landsdekkende leverandør for å levere nødanrop til riktig utsendelsessenter.

Alle kunder bør i det minste distribuere den grunnleggende konfigurasjonen for nødanrop. Grunn leggende nødanrop krever at minst ett kundeeid +E.164-nummer tildeles hvert sted som er definert i. For grunnleggende nødanrop vil hvert sted være definert av en gateadresse som politi, brann- eller ambulansetjenester sendes til i nødstilfeller. I de fleste tilfeller er hovednummeret for stedet det beste valget for å representere den fysiske plas seringen av nødsituasjonen. Vanligvis er tildelingen av adressen til+E.164-nummeret koordin ert med PSTN-leverandøren. Bildene nedenfor viser tildelingen av hoved nummeret som skal brukes som nødnummer for Richardson-stedet.

Plassering ECBN-konfigurasjon

I de fleste situasjoner er en bygningsadresse tilstrekkelig for forsendelsesadressen for stedet. Men hvis ytterligere posisjonsdetaljer er nødvendig for bestemte brukere eller enheter, kan en administrator bruke den samme prosessen som beskrevet ovenfor og tilordne disse enhetene til en bestemt adresse eller en mer presis plassering inne i adressen (som et gulv eller et rom). I Brukeradministras jon i tillater kategorien Anrop at et bestemt nummer kan brukes for en bruker og deres enheter for å få spesifikk utsendelsesadresse. Følgende bilder illustrerer hvordan et bestemt nummer kan tilordnes til en enhet. Administratoren er ansvarlig for å sørge for at nummeret som brukes av enheten, har riktig utsendelsesadresse tildelt den. Adres setildelingen gjøres vanligvis gjennom PSTN-leverandøren av det stedet.

Bruker ECBN-konfigurasjon

For USA-baserte telefonidistribusjoner som må tilby forbedrede nødanrop sløsninger, bruker RedSkys Horizon Mobility integrert i for ruting av nødanrop. Når du bruker RedSky for samtaleruting, må en administrator registrere seg for en konto gjennom Cisco og konfigurere riktig informasjon i C alling -> Service Settings for å aktivere denne funksjonen. Når RedSky- tjenesten er aktivert på systemnivå, vil en administrator aktivere RedSky- tjenesten på hvert posisjonsnivå. Aktivering av forbedret nødanrop på et sted vil aktivere tjenesten for alle enheter som er tilordnet det stedet. Enheter som støtter forbedret nødanrop er Cisco MPP-telefoner, Cisco PhoneOS-telefoner og Ciscos.

Det er to innstillinger for å aktivere forbedret nødanrop på et sted. Tillat RedSky å motta nettverkstilkoblingsinformasjon og testanrop bør brukes til å bekrefte at RedSky-konfigurasjonen for enhets- og infrastrukturtilordninger er riktig. Denne innstillingen gjør det også mulig å plassere testanrop til 933 for å utføre posisjons verifisering ved hjelp av RedSkys IVR-system for å lese ut plasseringen til den som ringer. Selv om dette dokumentet ikke dekker RedSky-konfigurasjonen for posisjonssporing, bør en administrator ALLTID teste stedsoppdagelsen før du aktiverer nødan rop for å rute til RedSky. Når testingen er fullført og bekreftet som nøyaktig, vil administratoren rute samtaler til RedSky ved å bytte rutens nødanrop til RedSky. Denne bryteren vil dirigere alle nødanrop for stedet til RedSky for levering til telefonsvareren for stedet.

Innstillingene for forbedret nødanrop gjelder også for klienter både lokalt og eksternt. Når det er lokalt, kan det spores på samme måte som skrivebordstelefoner spores. Når den er utenfor stedet, vil brukeren kunne angi plasseringen dynamisk direkte i. Hvis du vil ha mer informasjon om nødanrop, kan du se Forbed ret nødanrop for.

Lisensiering

Det er flere alternativer for å tilordne lisenser til brukere.

Manuell tildeling gjennom

Administratorer tilordner lisenser manuelt til individuelle brukere gjennom grensesnittet.

Administratorer kan redigere tjenestelisenser for individuelle brukere og tilordne anropslisenser direkte.

Automatiske lisenstildelingsmaler

Bruk lisenstildelingsmaler til å automatisk tilordne lisenser til brukere basert på gruppe- eller organisasjonsinnstillinger.

Automatisk lisensiering kan gjøres ved hjelp av katalogsynkronisering eller manuelle brukeroppdateringer, men brukerne må ha et gyldig+E.164-formatert telefonnummer og telefonnumrene må eksistere på et sted før brukerklargjøring. Hvis betingelsene ikke er oppfylt (f.eks. ugyldig telefonnummer format), tildeles ikke lisenser.

Massetildeling gjennom CSV-mal

Last opp en CSV-fil med brukerdetaljer og lisenstildelinger for å legge til eller endre flere brukere samtidig.

CSV-import støtter å legge til opptil 20 000 brukere og tilordne lisenser, men lisenser krever spesifikke felt som telefonnummer og utvidelse.

API-basert oppgave

Bruk API-er til å programmatisk tilordne lisenser og administrere brukere.

støtter API-operasjoner for bruker- og lisensadministrasjon (People, SCIM 2.0 og Licenses APIer), som kan utnyttes for automatisering av lisenstildeling. Lisens- API-en tillater samtidig tildeling av lisenser, telefonnumre og utvidelser.
Tabell 5. Brukerklargjøringsalternativer - sammendrag
Oppgavemetode Fordeler Ulemper
Manuell gjennom Enkelt for få brukere.
Tillater presis og detaljert kontroll over lisenstildeling.
Ikke skalerbar, tidkrevende
Utsatt for menneskelige feil under manuell oppføring.

Automatiske lisensmaler Skalerbar
Reduserer manuelle feil
Kan brukes på nye og eksisterende brukere.
Krever gyldige telefonnumre og steder.
Mer komplisert å sette opp
Krever også brukergrupper per gruppe brukere med tilsvarende lisensieringskrav.

Masseopplasting av CSV Effektiv for store brukersett
Tillater samtidig tildeling av lisenser, telefonnumre og utvidelser.
Krever nøye CSV-formatering
Potensial for feil hvis telefon numre eller utvidelser mangler eller er feil.
API-basert oppgave Automatiserbar, fleksibel.
Tillater samtidig tildeling av lisenser, telefonnumre og utvidelser.
Krever utvikling og API-kunnskap.

Tabellen Brukerklargjøringsalternativer - sammendrag oppsummerer brukerklargjøringsalternativer og fordeler og ulemper. Denne oversikten hjelper deg med å velge den beste lisenstildel ingsmetoden basert på kundeorganisasjonsstørrelse, automatiseringsfunksjoner og brukerklargjørings prosesser og krav.

Der det er mulig anbefaler Cisco å tilordne anropslisenser ved hjelp av lisensmaler. Dette krever at for hver gruppe brukere som krever et unikt sett med lisenser (Eksempel - Standard vs. Profesjonell) eksisterer en gruppe med de respektive gruppemedlemskapene. Som beskrevet i Brukergrupper- seksjonene, kan brukergrupper defineres manuelt i eller synkroniseres fra en bedriftskatalog. En kombinasjon av begge tilnærmingene er mulig.

Brukere som tilhører flere grupper, får lisenser fra alle oppgaver som brukes på alle gruppene deres. Dette gjør det mulig å bruke lisensspesifikke sikkerhetsgrupper i bedriftskatalogen til å administrere lisenstildeling der den resulterende brukerlisenstildelingen styres av foreningen av gruppemedlemskap.

Hvis du vil ha mer informasjon, kan du se Konfigur ere automatiske lisenstildelinger i Control Hub og Konfigurere automatiske lisenstildelingsmaler for Webex Calling brukere.

Lisenskrav

Denne delen dekker bare relaterte lisenser. Andre lisenstyper (Eksempel - Webex-enhetsregistrering, meldinger, møter) dekkes ikke. Som en del av designprosessen må lisenskravene bestemmes. Lisenstall for følgende lisenstyper må beregnes:

Standard: antall individuelle brukere som krever standard telefonfunksjoner.

Profes jonell: antall brukere og arbeidsområder som krever avanserte telefon funksjoner. Virtuelle linjer og gruppepost har rett til et 1:1 -forhold for hver profesjonell lisens. Derfor, i sjeldne tilfeller der antallet nødvendige virtuelle linjer eller gruppebeskjeder overstiger antall brukere og arbeidsområder som krever avanserte telefonif unksjoner, må det tas hensyn til ytterligere profesjonelle lisenser.

Arbeidsområde for fellesområde: antall delt bruk eller fellesarealer som krever standard samtalefunksjoner.

Kundeservice: antall agenter og veiledere som krever Customer Assist-funksjoner. Kundeservice inkluderer Professional-lisensen.

Ruteliste-anrop: antall påkrevde Cloud Connected PSTN-anrop mellom lokale brukere og/eller lokale spesialiserte tredjepartsapplikasjoner.

Attendant Console: antall brukere som trenger tilgang til den medfølgende konsollklienten.

Cisco Calling Plan (Outbound Calling Plan): antall brukere som trenger et PSTN- nummer og/eller utgående PSTN-anropstilgang for Cisco PSTN-tjenesten.

Det er ingen dedikert lisenstype for profesjonelle arbeidsområder. Profesjonelle arbeidsområder bruker en Professional-lisens.

Arbeidsområder kun for hot-desk tilbyr hotdesking-vertstjenesten og nødanrop fra hot-desking-verten og krever ingen lisens. Hvis du vil ha mer informasjon, kan du se Legge til og administrere bare Hot Desk-enheter.

Hvis du vil finne den nødvendige lisenstypen for hver bruker og arbeidsområde basert på funksjoner som trengs, kan du se Funksjoner tilgjengelig etter lisenstype for Webex Calling.

For å skille mellom funksjonalitet som tilbys av samtalekøer kombinert med den profesjonelle lisensen i motsetning til kundestøtte, se sammenligning av Webex Calling samtal ekø og kundestøtte.

Brukerklargjøring

Når du klargjør brukere i Webex, er det flere tilgjengelige alternativer, som hver passer til forskjellige organisasjonsbehov og miljøer:

Manuell klargj øring: Administratorer kan legge til og administrere individuelle brukere direkte innenfor. Denne metoden er grei, men best egnet for små organisasjoner eller begrensede bruker endringer.

Masseklarering gjennom CSV: For større brukerbaser kan administratorer importere og oppdatere brukere i bulk ved å laste opp CSV-filer til. Dette muliggjør effektiv styring av opptil tusenvis av brukere samtidig.

Alternativer for katalogsynkronisering:
Directory Connector: Dette er et automatisk synkroniseringsverktøy som brukes i Microsoft Active Directory miljøer. Den synkroniserer brukerkontoer, grupper og attributter på en planlagt basis (time, daglig eller ukentlig). Den støtter oppsett med flere domener og flere skoger Active Directory og kan synkronisere profilbilder og romobjekter.

Veiviserapp for Entra ID (Azure AD): Denne metoden er designet for organisasjoner som bruker Microsoft Entra ID (Azure AD), og gir automatisk synkronisering i nær sanntid av bruker kontoer og attributter direkte fra Entra ID til. Det er fullt administrert innenfor og krever minimalt oppsett.

SCIM 2.0-applikasjoner: For ikke-Microsoft-miljøer eller andre identitetsleverandører som Okta eller Duo, muliggjør SCIM-baserte synkroniseringsapper automatisk klargjøring og avklaring av brukere med attributttilordning og gruppesynkronisering.

Unified CMbrukersynkronisering: Dette alternativet gjør det mulig å opprette brukerkontoer basert på eksisterende sluttbrukere ved å synkronisere fra til. Dette krever at Cloud Connected UC (CCUC) kjører på lokale klynger. Imidlertid anbefales det generelt å synkronisere brukere fra en sentralisert skykatalog som Entra ID i stedet for direkte fra.

API-klargjøring: Offentlige API-er (People, SCIM 2.0) kan brukes til å klargjøre brukere. Hovedfordelen med å bruke API-er er muligheten til å integrere brukerklargjøring med andre bedriftssystemer.
Tabell 6. Alternativer for klargjøring av brukere for
Klargjøringsmetode Beskrivelse Fordeler Ulemper
Manuell Opprett/administrer brukere individuelt i Enkelt for få brukere; ingen infrastruktur nødvendig Ikke skalerbar; tidkrevende for mange brukere
Bulk (CSV-fil) Importer/oppdater brukere i bulk gjennom CSV i Effektiv for grupper; ingen koding kreves Manuell CSV-forberedelse; mindre dynamisk
Mennesker og SCIM 2.0 API Programmatisk brukeradministrasjon gjennom Webex APIer Fleksibel; støtter automatisering og integrering Krever utvikling og infrastruktur
Katalogsynkronisering Automatisk synkronisering fra AD, Entra ID, SCIM-apper, Unified CM Automatiserer livssyklus; støtter filtrering og kartlegging Oppsettkompleksitet: Noen av alternativene har begrensede funksjoner eller krever infrastruktur
Denne oversikten og tabellen gjenspeiler de viktigste alternativene for klargjøring av brukere, fordelene og begrensningene for å hjelpe deg med å velge den beste tilnærmingen for organisasjonens behov.

Brukergrupper

Brukergruppeadministrasjon i lar administratorer organisere brukere i grupper for effektiv masseadministrasjon av lisenser, innstillinger, og ressurser. Grupper bidrar til å effektivisere administrasjonen ved å bruke policyer, lisenser og innstillingsmaler på flere brukere samtidig, i stedet for å administrere brukere individuelt.

Brukergruppeadministrasjon gir flere fordeler, inkludert:

Forenklet administrasjon: Administrer lisenser, innstillinger og policyer for flere brukere samtidig.

Konsist ens: Bruk ensartede innstillinger og lisenser på tvers av brukere i samme gruppe.

Skalerbarhet: Støtter opptil 250 000 medlemmer per gruppe.

Integrering: Synkroniser grupper fra Microsoft Entra ID (Azure AD) eller Active Directory for automatisert bruker- og gruppeadministrasjon.

Fleksibilitet: Opprett lokale grupper eller synkroniser sikkerhetsgrupper; administrer grupp emedlemskap manuelt eller gjennom CSV-filer.

Ressursfordeling: Kontroller tilgangen til innebygde apper og tjenester basert på gruppemedlemskap.

De viktigste brukstilfellene for brukergrupper ved klargjøring er:

Lisenstil delinger: Tilordne lisenser til grupper for automatisk å levere tjenester som samtaler, møter, meldinger eller hybridtjenester til gruppemedlemmer.

Innstillingsmaler: Bruk samlinger av tjenesteinnstillinger (f.eks. meldinger, møte, samtaler) på grupper for jevn brukeropplevelse.

Massebrukeradministras jon: Legg til eller fjern brukere i bulk gjennom CSV-filer eller katalog synkronisering.

Automatisering og integrering: Bruk API-er eller katalogsynkronisering for automatisert bruker- og gruppens livssyklusadministrasjon.

Tabellen nedenfor oppsummerer de forskjellige alternativene for å administrere brukergrupper og gruppe administrasjon i.
Tabell 7. Alternativer for å administrere grupper og gruppemedlemskap
Alternativet Beskrivelse Fordeler Ulemper

gruppeklarering (grupper) Opprett og administrer grupper direkte i. Legg til/fjern medlemmer manuelt eller via CSV. Full kontroll over gruppemedlemskap
Umiddelbar anvendelse av lisenser og maler
Enkelt å opprette og redigere grupper Manuelle oppdateringer kreves
Fare for feil i manuelle CSV-opplastinger
Ingen automatisk synkronisering med eksterne kataloger

Synkroniserte grupper fra Entra ID (Azure AD) eller Active Directory Synkroniser sikkerhetsgrupper og medlemskap automatisk fra eksterne katalog tjenester. Automatisert synkronisering reduserer manuelt arbeid
Sikrer konsistens med bedriftskatalog
Støtter store organisasjoner
Kan ikke redigere gruppemedlemskap i
Synkroniseringsforsinkelse opptil 12 timer
Nestede grupper krever manuell markering

Grupper og SCIM 2.0 API (grupper) Bruk Grupper eller SCIM 2.0 API for programmatisk gruppe- og medlemsadministrasjon Automatisering og integrering med andre systemer
Skalerbar for store eller komplekse miljøer
Krever utviklingsinnsats
Kompleksitet avhenger av API-bruk

Mens synkroniserte grupper sikrer konsistens og tilbyr ett enkelt administrasjonspunkt, er en hybrid tilnærming som kombinerer synkroniserte grupper og grupper (enten administrert i kontrollhub eller gjennom API-er) mulig. Så for eksempel kan grupper for lisenstildeling være synkroniserte grupper, og et eget sett med grupper kan brukes til å tilordne bruker- og anropsmaler.

Denne omfattende tilnærmingen til administrasjon av brukergrupper gjør det mulig for organisasjoner å administrere brukerlisenser, innstillinger, og policyer effektivt, og sikre konsistente og skalerbare samarbeidsopplevelser.

Anbefalt tilnærming når du migrerer fra til

Den primære datakilden for brukere på er databasen, som inneholder sluttbrukerinformasjon. derimot, er ikke typisk den autoritative kilden for brukeridentitetsadministrasjon og enda viktigere vil bli stengt ved slutten av overgangen og er derfor utelukket som langsiktig autoritativ kilde for identitetsinformasjon.

Cisco anbefaler å bruke en sentralisert skykatalog som Microsoft Entra ID (Azure AD) som den eneste kilden til sannhet for brukeridentiteter. Synkronisering av brukere fra Entra ID for å sikre konsistens, forenkler administrasjonen og støtter funksjoner for enkel pålogging (SSO).

For å sikre at alle brukere på også er til stede i Entra ID, bør organisasjoner kontrollere at brukerkontoene i samsvarer med kontoer i Entra ID. Dette kan gjøres ved å eksportere brukerlister fra og sammenligne dem med Entra ID-brukerlister.

Oppsummert er den anbefalte klargjøringsmetoden å synkronisere brukere fra Microsoft Entra ID (Azure AD) til Webex ved hjelp av Azure AD-veiviseren eller SCIM-appene. Manuell og CSV-masseklargjøring er tilgjengelig som tilleggsmetoder, men er mindre skalerbar og mer utsatt for feil for store organisasjoner. Å sikre at Entra ID er den autoritative kilden og at alle brukere eksisterer i Entra ID er avgjørende for en vellykket migrering og konsekvent bruker opplevelse på tvers av miljøer.

Overgang fra en lokal katalogtjeneste, for eksempelActive Directory, til en skykatalogtjeneste, som Entra ID (Azure ID), er uavhengig av anropsovergangen. Cisco anbefaler å fullføre over gangen til en skykatalogtjeneste før du starter anrops overgangen.

Utforming av brukergrupper

Etter overgang av bedriftskatalogen fra lokal til skyen samler du de nødvendige brukergruppene drevet av lisensierings- og funksjonsmalkrav . For hvert gruppedokument:

Gruppenavn: unikt navn på gruppen.

Lisenser: lisenser som skal tilordnes denne gruppen (hvis noen) og omfang (bør lisenser tilordnes eksisterende brukere eller bare til nye brukere)

Innstillingsmaler: Webex App- og Brukersamtalemaler.

Katalogsynkronisering: Vil denne gruppen synkroniseres fra bedriftskatalogen, eller er dette en lokal Webex-gruppe klargjort i Control Hub eller gjennom en API.

Beskrivelse: hvordan vil denne gruppen bli brukt og hvilke brukere som skal være medlemmer av denne gruppen

Disse detaljene vil bli brukt senere i implementeringsfasen for å opprette lokale grupper eller grupper i bedriftskatalogen og administrere gruppemedlemskap for brukere.

Enkel pålogging (SSO)

Cisco anbefaler bruk av SSO for brukerautentisering. Å bruke SSO har noen overbevisende fordeler, inkludert:

Forenklet brukerautentisering: Brukere kan logge på én gang ved å bruke bedrift slegitimasjonen (f.eks. fra Azure ID) for å få tilgang til og andre integrerte applikasjoner, noe som eliminerer behovet for flere passord og reduserer påloggingsforespørsler. Dette forbedrer sikkerheten ved å sikre at bedriftspassord aldri lagres eller overføres til etter godkjenning.

Forenklet brukeradministrasjon: Automatiserer oppretting, oppdateringer og deaktivering av brukerkontoer basert på endringer i bedriftskatalogen, reduserer administrative kostnader og sikrer at bare autoriserte brukere har tilgang.

Forbedret sikkerhet: SSO reduserer passordutmattelse og risikoen for passordrelaterte brudd ved å sentralisere autentisering gjennom pålitelige identitetsleverandører (IDP).

Enkel integrering av multifaktorautentisering (MFA): MFA kan enkelt støttes enten gjennom en Identity Access Management- løsning som Cisco Duo eller gjennom MF A-støtte for IdP.

Det er flere alternativer for å implementere SSO for tjenester:

SAML 2.0-basert SSO: Den primære protokollen som støttes for S SO-integrasjon, muliggjør sikker utveksling av autentiseringsinformasjon mellom Id P og tjenesteleverandøren.

OpenID connect (OIDC): Støttes som en alternativ moderne autentiseringsprotokoll for SSO-integrasjon.

Webex-identitet: Støttes også som et alternativ for identitetsleverandør.

SSO konfigureres og administreres sentralt gjennom, noe som krever metadatautveksling mellom og den valgte IdP.

Etter konfigurasjon kan SSO testes innen før aktivering for å sikre riktig oppsett.

Cisco støtter integrasjon med flere testede og ofte brukte IDP-er og Identity Management Systems (IAM), inkludert, men ikke begrenset til:

Cisco Duo

Okta

Microsoft Active DirectoryFøderasjonstjenester (ADFS)

Microsoft Azure

Ping Federate

OpenAM

F5 BIG-IP.

Disse IDP-ene samsvarer med SAML 2.0- eller OpenID Connect-standarder og er validert for kompatibilitet med Ciscos samarbeidsløsninger.

Støtte for flere IdP

lar organisasjoner konfigurere SSO med flere IDP-er for å imøtekomme komplekse IT- miljøer som fusjoner, oppkjøp eller desentraliserte IT-avdelinger der forskjellige grupper bruker forskjellige IDP-er. Støtte for flere IdP kan enten implementeres ved hjelp av Multi ple IdP-funksjonen i eller gjennom integrering av et bedrifts IAM-system som Cisco Duo.

Støtte for flere identitetsleverandører (IdP) adresserer flere viktige brukstilfeller der organisasjoner krever fleksibel og sikker autentisering på tvers av ulike IT-miljøer:

1. Fusjoner og oppkjøp

Når selskaper fusjonerer eller kjøper andre, har de ofte separate IT-infrastrukturer og distinkte IDP-er som ikke kan føderere seg. Støtte for flere IdP gjør det mulig for brukere fra begge organisasjoner å autentisere og samarbeide sikkert uten å måtte forene identitetssystemene sine umiddelbart.

2. Flere uavhengige IT-avdelinger

Store organisasjoner eller offentlige institusjoner kan ha flere uavhengige IT-avdelinger, som hver administrerer sin egen IdP. Den flere IdP-funksjonen gjør det mulig for disse avdelingene å opprettholde sine egne autentiserings systemer samtidig som brukerne får tilgang sømløst.

3. Ulike brukergrupper eller domener

Organisasjoner med ulike brukergrupper (f.eks. ansatte kontra entreprenører) eller flere e-post domener kan konfigurere rutingsregler for å dirigere godkjenningsforespørsler til riktig IdP basert på domene- eller gruppemedlemskap. Dette støtter differensierte tilgangspolicyer og sikkerhet skontroller.

4. Støtte for ulike autentiseringsprotokoller

støtter SAML- og OpenID Connect (OIDC) IDP-er, slik at organisasjoner kan integrere forskjellige typer identitetsleverandører i henhold til deres eksisterende infrastruktur og sikkerhetskrav.

5. Forbedret sikkerhet og samsvar

Ved å aktivere flere IDP-er kan organisasjoner implementere sterkere autentiseringsmekanismer, inkludert multifaktorautentisering (MFA) gjennom integrasjoner som Duo, og håndheve konsistente sikkerhetspolicyer på tvers av ulike brukerbaser.

6. Forenklet brukeropplevelse

Brukere kan autentisere ved hjelp av eksisterende legitimasjon fra sine respektive IDP-er, noe som gir en enhetlig påloggingsopplevelse til tross for den underliggende kompleksiteten til flere identitetssystemer.

Selv om flere IdP-støtte gir fleksibilitet, krever det nøye koordinering mellom sikkerhets- og identitetsteam for å opprettholde konsistente sikkerhetspolicyer og unngå potensielle sårbarheter.

Duo MFA med SSO for

Duo Access Gateway (DAG) kan autentisere brukere ved hjelp av eksisterende lokale eller skybaserte kataloger som Active Directory (AD) og OpenLDAP. Den støtter også integrasjon med andre identitetsleverandører som Microsoft ADFS, Microsoft Azure, Okta, OneLogin, CAS og Shibboleth. Denne fleksibiliteten gjør det mulig for organisasjoner å bruke sin nåværende katalog infrastruktur for Webex SSO med Duo MFA.

Duo fungerer som et sterkt autentiseringslag på toppen av den primære katalogautentiseringen. Den fungerer som en identitetsleverandør (IdP) ved hjelp av SAML 2.0 for å håndheve tofaktorautentisering (2FA) før du gir tilgang til. Duo evaluerer bruker-, enhets- og nettverkskontekst mot konfigurerbare retningslinjer for å tillate eller nekte tilgang, noe som forbedrer sikkerheten utover bare brukernavn og passord. Duo gir også fleksible policykontroller, for eksempel å kreve MFA ved hver pålogging for noen apper og sjeldnere for andre.

Fordelene med Cisco Duo inkluderer:

Forbedret sikkerhet: Leg ger til phishing-resistent MFA for å beskytte tilgang, og reduserer risikoen fra kompromitterte passord.

Fleksible policyer: Tillater detaljert kontroll over godkjenningskrav per applikasjon eller brukergruppe.

Integrasjon med eksisterende kataloger: Stø tter lokal AD, OpenLDAP, sky kataloger og ulike SSO-leverandører, noe som minimerer endringer i infrastruktur.

Brukervennlighet: Stø tter enkel pålogging (SSO) for å redusere passordutmattelse ved å gjøre det mulig for brukere å logge på én gang og få tilgang til flere ressurser på en sikker måte.

Klarerte endepunkter: Stø tter enhetstillit for klienter på Windows og macOS, noe som forbedrer sikkerhetsstillingen.

Selvbetjeningsregistrering: Inline-påmelding og duo-prompt forbedrer brukeropplevelsen under MFA-oppsett.

Duo MFA med SSO for utnytter eksisterende kataloger som Active Directory og OpenLDAP, eller skyidentitet sleverandører, for å autentisere brukere. Duos rolle er å tilby en sterk, policydrevet andre autentiserings faktor integrert gjennom SAML 2.0, noe som forbedrer sikkerheten samtidig som brukervennligheten opprettholdes gjennom SSO. Fordelene inkluderer forbedret sikkerhetsstilling, fleksibel håndheving av policyer, sømløs integrasjon og en bedre brukeropplevelse.

Cisco anbefaler å implementere SSO for brukere. For forbedret sikkerhet anbefales integrasjon med Cisco Duo.

Enterprise IAM- og SSO-strategien bør implementeres før overgangen fra til starter.

Funksjoner

har et komplett utvalg av kjernefunksjoner som følger med tjenesten. Dette inkluderer mange anropsfunksjoner i bedriftsklasse som har vært tilgjengelige i mange år. Du ser kanskje ikke 100% paritet mellom funksjoner og funksjoner, men som du kan se i figuren nedenfor, er de viktigste anropsfunksjonene tilgjengelige i.

Webex Callingfunksjoner i bedriftsklassen

Foruten de mange brukerfunksjonene, har kjernesystemfunksjoner som følger med plattformen. Disse inkluderer funksjoner som autovertakere, samtalekøer, anropspark, etc. Du kan se alle tilgjengelige kjernesystem funksjoner under Service → Anrop → Funksjoner som vist i figur Webex Callingkjerne funksjoner.

Webex Callingkjernefunksjoner

Automatisk ledsager

Auto Attendant muliggjør 24/7 automatisering av håndtering av innkommende anrop, noe som muliggjør effektiv samtalehåndtering uten at en person trenger å svare på hvert anrop.

Den automatiske svartjenesten svarer på innkommende anrop og gir den som ringer en meny med alternativer for hvor de vil dirigere samtalen. Dette kan være til en person, en telefonsvarerboks eller en anropstjeneste (f.eks. Anropskø). Den som ringer bruker telefonens nummertastatur for å skrive inn nummeret fra den automatiske svar menyen.

Auto Attendant støtter følgende viktige funksjoner:

Forretnings- og ettertidsplaner

Ferieplan

Alternativet for oppringingsmeny for å lede kundene dine dit de trenger å gå

Tilpass hilsener

Alternativ for å ringe etter navn

Alternativer for viderekobling av anrop

Control Hub-analyser og rapporter.

Hvis du vil ha mer informasjon, kan du se Administrer automatiske svartjenester.

Ring Park

Call park gir brukerne muligheten til enkelt å sette et anrop på vent slik at en annen bruker enkelt kan hente når de er tilgjengelige for å ta det. Det frigjør også brukeren som svarte på det opprinnelige anropet for å ringe eller motta andre samtaler mens samtalen er parkert.

Det er to typer anropsparker tilgjengelig i:

Call park direct - gjør det mulig for enhver bruker å parkere et anrop til en annen brukers utvidelse eller til en samtaleparksutvidelse, som definert av administratoren

Anropsparkgruppe - lar en definert gruppe brukere automatisk parkere anrop mot tilgjengelige parkdestinasjoner definert for gruppen. Disse destinasjonene kan være gruppemedlemmenes utvidelser eller anropsparkutvidelser.

Basert på konfigurasjon og parkeringstype kan brukere hente anrop ved å ringe *88+><extension of parked call>, trykke på linjetasten som er knyttet til anropsparkutvidelsen eller bruke en funksjonstast på IP-telefonen.

Et tilbakekallingsalternativ er tilgjengelig for å tilbakekalle et parkert anrop etter en spesifisert periode til brukeren som parkerte samtalen eller til en alternativ bruker.

Hvis du vil ha mer informasjon, kan du se Administrer anropsparkering i Control Hub.

Henting av anrop

Henting av anrop gjør det mulig for en administrator å definere en gruppe brukere (medlemmer) som kan svare på et an rop til et annet medlems telefon. Dette gir en bruker muligheten til å svare på anrop når lagkameratene er opptatt og ikke kan svare på et innkommende anrop.

Brukerne i en gruppe må være på samme sted.

Brukere kan bruke enten skrivebordstelefonen eller skrivebordstelefonen til å hente en samtale.

:

Støtter visuelle og lydvarsler

Varsling om innkommende anrop

FAC-basert (ring *98) eller varslingsopptak

Varsler om henting av anrop for multilinje.

Skrivebordstelefoner:

Varsling om innkommende anrop

Lydklokkespill og visuell varsling gjennom håndsettets LED. 6821 støtter bare lydklokker

Når varslingstypen er valgt i er ikke ingen

Varsler om henting av anrop bare for primære linjer.

Hvis du vil ha mer informasjon, kan du se Konfigurere samtaleopptak sgruppe.

Anropskø

inkluderer kun taleanropskøer som en del av kjernefunksjonene, og enhver bruker med en Professional-lisens kan være en del av en anropskø, agent eller veileder. Denne funksjonen lar brukerne effektivt engasjere seg med kunder. Samtalekøer støtter et delsett av noen av kjernefunksjonene i kundes enteret som talekøer, tilbakeringing, ferdighets- eller prioritetsruting, agentkø styring, analyse, rapportering, etc.

Ciscos oppfordring til Microsoft Teams-integrasjon gir agenter tilgang til anropskøanrop og funksjoner direkte fra Microsoft Teams-klienten.

Anropskøer støtter følgende viktige funksjoner:

Hilsener og meldinger (velkommen, komfort, hvisking osv.)

Hold musikk

Tilbakeringing

Retningslinjer for køruting (natttjeneste, helligdager, videresending)

Pålogging/utlogging av agentkø

Administrasjon av agentkøstatus

eller skrivebordstelefonstøtte

Veilederagent ringer overvåking, trener, lekter eller overtar gjennom Feature Access Codes (FACs)

(administratortilgang) for:

køadministrasjon

Agent- og køanalyse og rapportering

Kø-, agent- og veilederledelse.

Hvis du vil ha mer informasjon, kan du se Konfigurere anropskø.

har en tilleggsfunksjon for kundeassistanse som gir ekstra anropskøfunksjoner og gir agenter og veiledere en bedre brukeropplevelse innen. Hvis du vil ha en sammenligning av funksjonene Anropskø og Kundeservice, kan du se Sammenligning av funksjoner for an Webex Calling ropsk ø og kundestøtte.

Jaktgruppe

Jaktgrupper tillater ruting av innkommende anrop til en bestemt gruppe brukere gjennom et forhåndsbestemt samtalerutingsmønster. Dette sikrer at samtaler besvares av riktig gruppe brukere eller sendes til en telefonsvarer for oppfølging.

En stor forskjell mellom Hunt Groups og Call Queues er at samtaler ikke står i kø i en Hunt Gro ups, så hvis ingen brukere i Hunt Group er tilgjengelige for å svare på samtalen, vil den bli koblet fra, sendt til telefonsvarer eller videresendt til et annet nummer (bruker eller tjeneste).

Hvis du vil ha mer informasjon, kan du se Administrer jaktgrupper i Control Hub.

Driftsmoduser

Funksjonen Operating Modes lar bedrifter effektivt rute samtaler til forskjellige destinasjoner (brukere, telefonsvarer, ringetjenester som en anropskø). Hvor og når et anrop rutes er basert på en tids plan for tid på dagen og ukedag, og enhver bruker kan autoriseres til å administrere disse modusene (tidsplanene) for å kontrollere endringer i samtalerutingen.

For eksempel kan anrop til en anropskø rutes til en annen anropskø med agenter i en annen tidssone for å svare på anrop etter arbeidstid, i arbeidstid rutes til lokale agenter, og i løpet av helligdager rutes til telefonsvarer for opp følging etter at agenter kommer tilbake til kontoret.

En autorisert bruker kan bytte mellom disse forskjellige viderekoblingsscenariene (modusene) hvis de trenger å endre hvor innkommende anrop rutes i en viss periode. Disse brukerne kan administrere modus ene gjennom 6800/7800/8800 MPP-telefoner, 9800-telefoner eller i brukernavet i Administrer moduser.

Hvis du vil ha mer informasjon, kan du se Anropsruting basert på driftsmoduser i Webex Calling.

Personsøkingsgruppe

Personsøkingsgrupper lar brukerne ringe en enveis samtale for å sende en lydmelding til en gruppe brukere. Hver gruppe kan inneholde opptil 75 målbrukere og/eller arbeidsområder som nås ved å ringe et forhånds definert nummer eller en utvidelse.

Når en bruker kaller en personsøkingsgruppe, blir det foretatt et samtidig anrop til alle de tildelte målene i gruppen, på hvilket tidspunkt den som ringer kan snakke meldingene sine og legge på når de er ferdige.

Hvis du vil ha mer informasjon, kan du se Konfigurere en personsøkingsgruppe i Control Hub.

Innspillinger

støtter opptak av samtaler foretatt eller mottatt av en bruker. Dette kan være nødvendig for kvalitet, sikring, sikkerhet eller opplæringsbehov. Som standard blir samtaler spilt inn, men andre tredjeparts opptaksleverandører kan også brukes hvis andre opptaks funksjoner eller samsvar og forskriftskrav er påkrevd.

Når du bruker som opptaksplattform, administreres alle innspilte samtaler innenfor. Fullstendige administratorer med rollen som Compliance Officer kan spille og laste ned opptakene. Uten rollen som Compliance Officer kan administratoren bare slette opptakene.

Hvis du vil ha mer informasjon om denne funksjonen og en liste over tredjepartsopptak, kan du se Administrer anrops opptak for Webex Calling.

Enkeltnummerrekkevidde

Enkeltnummerrekkevidde gjør det mulig å ringe til en brukers telefonnummer for å ringe flere enheter. Dette kan omfatte andre skrivebordstelefoner så vel som mobiltelefoner. Samtaler kan også plasseres fra disse enhetene, og brukere kan skyve og trekke samtaler mellom dem.

Hvis du vil ha mer informasjon om denne funksjonen og hvordan en administrator konfigurerer den, kan du se Konfigurere enkeltnummerrekkevidde (kontor hvor som helst).

Hvis du vil ha mer informasjon om hvordan en bruker kan administrere og konfigurere denne funksjonen for seg selv i Webex User Hub (portalen), kan du se Konfigurere enkeltnummerrekke vidde (kontor hvor som helst).

Talepostgruppe

Talepostgrupper tillater en delt talepostboks som kan tilordnes en bruker- eller samtalerutingsfunksjon. Noen av grunnene til at en talepostgruppe kan være nødvendig er:

Generell telefonsvarer for en avdeling eller arbeidsgruppe

Legg til talepostalternativ til en automatisk svartjeneste eller jaktgruppe

Slik sender du overløpsanrop fra en anropskø

Brukere som bare trenger en talepostboks.

Hvis du vil ha mer informasjon, kan du se Administrer en delt talepost og innkommende faksboks for. Webex Calling

Attendant Console er oppført på siden Anropsfunksjoner i Webex, men det er en tilleggsfunksjon som krever kjøp av den medfølgende konsoll lisensen for å bruke.

Hvis du vil ha mer informasjon, kan du se Komme i gang med Attendant Console.

Hvis du vil ha informasjon om alle funksjoner, inkludert noen tilleggsfunksjoner, kan du se Funksjoner tilgjengelig etter lisenstype for Webex Calling.

Tabell 1. Informasjon som skal innhentes for hvert sted
Informasjon	Kommentar
Utvidelsesområde (er)	Hvert sted i kan ha utvidelser som starter med forskjellige sifre. Ett siffer må spares for styr ingssifferet mellom lokalene (for eksempel 8) og ett for PSTN- styresifferet (for eksempel 9). Ingen utvidelsesområde kan starte med noen av disse to sifrene. Alle utvidelsesområder på alle steder må være like lange.
DID-område (er)	-
PSTN styringssiffer	-
Nettstedskode	Alle nettstedskoder for alle steder må være unike og ha samme lengde.
Hovednummer	Når du oppretter et sted, må to DID-er klargjøres. Ett som hovednummer (for eksempel for å tilordnes en automatisk svartjeneste) og ett for telefonsvar erportalen. Bestem en DID for telefonsvarernummeret.
Talepostnummer
Antall lisenser	Nødvendige lisenser etter type inkludert Standard, Professional, Workspace, Ruteliste, Utgående anropsplan.
Samtidige samtaler i den travle timen	Summen av samtidige samtaler mellom enheter og mellom enheter og den lokale gatewayen (PSTN og anrop til enheter). Nødvendig for å bestemme den nødvendige båndbredden til internettilgang.
Land	-
Tidssone	-
Språk	-
Kontakt (Navn, Telefon, E-post)	-
Adresse (Gateadresse, by, stat, postnummer)	-
Nødetjenestens fysiske utsendelsessted for endepunkter	Enhetsforsendelsessted som brukes til nødanrop inkluderer vanligvis følgende: bygningsadresse, bygningsadresse + etasjenummer, bygningsadresse+ suitenummer eller bygningsadresse + etasjenummer+kontor/kubisk nummer.
Per enhet unik fysisk nettverksplassering for nødetjenester	Fysisk nettverksplassering for nødanrop inkluderer vanligvis følgende: svitsj/bryterport for kablede enheter, BSSID-er (Basic Service Set Identifiers) for trådløst tilkoblede enheter og/eller lokale IP-delnett (er) for endepunktsenheter.

Tabell 2. Eksempel på bedriftsnummerering
Nettstedet	Utvidelsesområde	Nettstedskode	Enterprise-utvalg
NYC	2XXX	202	8 202 2XXX
SFO	3XXX	203	8 203 3XXX
RTP	2XXX	204	8 204 2XXX

Tabell 3. Faste lengdeforlengelsesområder
Nettstedet	Utvidelsesområde	Utvidelser	Nettstedskode	Enterprise-utvalg
NYC	2XXX	2XXX	202	8 202 2XXX
SFO	8XXX	7XXX	203	8 203 7XXX
RTP	1XX	11XX	204	8 204 11XX

Tabell 4. Overgang av syv-sifret oppringing

Nettstedet	Utvidelser	Nettstedskode	Enterprise-utvalg	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

Tabell 5. Brukerklargjøringsalternativer - sammendrag
Oppgavemetode	Fordeler	Ulemper
Manuell gjennom	Enkelt for få brukere. Tillater presis og detaljert kontroll over lisenstildeling.	Ikke skalerbar, tidkrevende Utsatt for menneskelige feil under manuell oppføring.
Automatiske lisensmaler	Skalerbar Reduserer manuelle feil Kan brukes på nye og eksisterende brukere.	Krever gyldige telefonnumre og steder. Mer komplisert å sette opp Krever også brukergrupper per gruppe brukere med tilsvarende lisensieringskrav.
Masseopplasting av CSV	Effektiv for store brukersett Tillater samtidig tildeling av lisenser, telefonnumre og utvidelser.	Krever nøye CSV-formatering Potensial for feil hvis telefon numre eller utvidelser mangler eller er feil.
API-basert oppgave	Automatiserbar, fleksibel. Tillater samtidig tildeling av lisenser, telefonnumre og utvidelser.	Krever utvikling og API-kunnskap.

Tabell 6. Alternativer for klargjøring av brukere for
Klargjøringsmetode	Beskrivelse	Fordeler	Ulemper
Manuell	Opprett/administrer brukere individuelt i	Enkelt for få brukere; ingen infrastruktur nødvendig	Ikke skalerbar; tidkrevende for mange brukere
Bulk (CSV-fil)	Importer/oppdater brukere i bulk gjennom CSV i	Effektiv for grupper; ingen koding kreves	Manuell CSV-forberedelse; mindre dynamisk
Mennesker og SCIM 2.0 API	Programmatisk brukeradministrasjon gjennom Webex APIer	Fleksibel; støtter automatisering og integrering	Krever utvikling og infrastruktur
Katalogsynkronisering	Automatisk synkronisering fra AD, Entra ID, SCIM-apper, Unified CM	Automatiserer livssyklus; støtter filtrering og kartlegging	Oppsettkompleksitet: Noen av alternativene har begrensede funksjoner eller krever infrastruktur

Tabell 7. Alternativer for å administrere grupper og gruppemedlemskap
Alternativet	Beskrivelse	Fordeler	Ulemper
gruppeklarering (grupper)	Opprett og administrer grupper direkte i. Legg til/fjern medlemmer manuelt eller via CSV.	Full kontroll over gruppemedlemskap Umiddelbar anvendelse av lisenser og maler Enkelt å opprette og redigere grupper	Manuelle oppdateringer kreves Fare for feil i manuelle CSV-opplastinger Ingen automatisk synkronisering med eksterne kataloger
Synkroniserte grupper fra Entra ID (Azure AD) eller Active Directory	Synkroniser sikkerhetsgrupper og medlemskap automatisk fra eksterne katalog tjenester.	Automatisert synkronisering reduserer manuelt arbeid Sikrer konsistens med bedriftskatalog Støtter store organisasjoner	Kan ikke redigere gruppemedlemskap i Synkroniseringsforsinkelse opptil 12 timer Nestede grupper krever manuell markering
Grupper og SCIM 2.0 API (grupper)	Bruk Grupper eller SCIM 2.0 API for programmatisk gruppe- og medlemsadministrasjon	Automatisering og integrering med andre systemer Skalerbar for store eller komplekse miljøer	Krever utviklingsinnsats Kompleksitet avhenger av API-bruk

Implementere

Nettverksberedskap

Innledende oppsett

Domenebekreftelse

Gjør krav på (konverter) eksisterende brukere

Konfigurer og test katalogsynkronisering

Konfigurere og teste Single Sign-On (SSO)

Anskaffe, levere og verifisere lisenser

Webex Callingtjenesteinnstillinger

Pilotmigrasjon

Anskaffe PSTN

Konfigurer lokasjoner

Integrasjon med lokal samtalekontroll

Overfør brukere i grupper

Arbeidsområder

Tilveiebringsenheter

Konfigurer funksjoner

Godkjenningstesting

Nettverksberedskap

Det første trinnet i overgangen til er å sikre pålitelig og sikker Internett-tilkobling mellom det lokale nettverket og skyen.

Siden de fleste organisasjoner kobler seg til internett via en eller flere brannmurer eller sikkerhetsenheter, er det viktig å validere at de nødvendige trafikkstrømmene støttes.

Nettverks- og sikkerhetsadministratorer må forstå disse flytene i form av:

Retning (innkommende vs utgående)

Protokoller (Eksempel - SIP TLS, SRTP, HTTPS)

IP-adresseområder som brukes av tjenester

Portnumre som må åpnes eller tillates.

Dette sikrer at bedriftens brannmurer, NAT-enheter og annen nettverksinfrastruktur er riktig konfigurert for å imøtekomme trafikk samtidig som bedriftens sikkerhetspolicyer opprettholdes.

For informasjon om nødvendige flyter, inkludert IP-adresse, porter, og protokoller, se Portreferanseinformasjon for Webex Calling. Bruk denne informasjonen til å konfigurere brannmuren, proxyer og annen nettverksinfrastruktur i den eksisterende distribusjonen for å aktivere nettverksflyter.

Desentralisert internettutbrudd fra hver filial eller nettsted er den anbefalte tilnærmingen for skysamarbeidstjenester som. Ved å la trafikken gå ut lokalt, gjør denne modellen følgende:

Reduserer tur-returforsinkelse og jitter, og forbedrer den generelle samtalekvaliteten

Skalerer effektivt etter hvert som flere brukere og nettsteder går over til

Fungerer sømløst med SD-WAN, som dynamisk kan rute økter til nærmeste skyinngangspunkt for optimal ytelse

Tillater å spore brukerplassering basert på deres offentlige IP-adresse, noe som hjelper med mediebane analyse og feilsøking.

I tillegg må organisasjoner sørge for tilstrekkelig internettbåndbredde på hvert nettsted. Bå ndbredde bør dimensjoneres basert på forventet antall samtidige anrop, den valgte kodeken (f.eks. Opus eller G.711), pluss overhead for signalering, retransmisjoner og vekst. Dette stemmer overens med forberedelsesfasen i PPDIO-livssyklusen og etablerer et solid fundament for migrering.

Innledende oppsett

Den første oppsettdelen i implementeringsfasen av distribusjonen er grunnleggende for å etablere et godt strukturert og håndterbart skyanropsmiljø. Dette stadiet omfatter kritiske oppgaver som å sette opp organisasjonen, anskaffe og tildele lisenser, og verifisere og gjøre krav på bedriftens domener for å sikre riktig brukeradministrasjon og sikkerhet. I tillegg inkluderer den klargjørings lisensmaler for å automatisere tildelinger av brukerlisenser, konfigurere Single Sign-On (SSO) for å effektivisere brukerautentisering og forbedre sikkerheten, og justere tjeneste- og klientinnstillinger slik at de stemmer overens med organisasjonspolicyer og brukerbehov. Å fullføre disse innledende konfigur asjonsaktivitetene sikrer at miljøet er riktig konfigurert for skalerbarhet, sikkerhet og sømløs brukeropplevelse, og setter scenen for påfølgende distribusjons- og driftsfaser.

Domenebekreftelse

For å kunne identifisere brukere som er registrert med bedriftens e-postdomener på, er det viktig å bekrefte domenene dine. Uten domenebekreftelse vil brukere bli tildelt en forbrukerorganisasjon, noe som kompliserer brukeradministrasjonen for bedriften din. Domenebekreftelse er et obligatorisk trinn som gjør at organisasjonen din kan kreve og administrere disse brukerne effektivt.

Sørg for at alle domener som er knyttet til brukernes e-postadresser er bekreftet. Domene bekreftelse er ikke eksklusiv; det samme domenet kan verifiseres på tvers av flere organisasjoner.

Hvis du vil ha mer informasjon om hvordan du administrerer domener, kan du se Administrer domenene dine.

Gjør krav på (konverter) eksisterende brukere

Etter at du har bekreftet domenene dine, kan du fortsette å gjøre krav på brukere som har registrert seg for å bruke bedriftens e-postdomener i organisasjonen. Denne prosessen konsoliderer alle brukere under en enkelt organisatorisk paraply, noe som muliggjør sentralisert administrasjon og strømlinjeformet administrasjon. Ved å gjøre krav på disse brukerne sikrer du at bedriften din har full kontroll over brukerkontoer, slik at du kan tilordne passende lisenser, konfigurere tjenester og gi nødvendig støtte effektivt. Denne enhetlige administrasjonsmetoden forbedrer sikkerheten, forenkler klargjøring av brukere og sikrer jevn tilgang til tjenester i hele organisasjonen. Å hevde brukere forhindrer dem også i å bli administrert i eksterne organisasjoner eller forbrukerorganisasjoner, og opprettholder dermed organisasjonsintegritet og kontroll over samarbeidsressurser.

Hvis du vil ha mer informasjon om hvordan du gjør krav på brukere, kan du se Gjør krav på brukere av organisasjonen (konverter).

Konfigurer og test katalogsynkronisering

Hvis du vil aktivere sømløs bruker- og gruppeadministrasjon, kan du synkronisere brukere og grupper fra bedriftskatalogen enten Microsoft Entra ID (tidligere Azure AD) eller Microsoft Active Directory (AD) til. Denne prosessen sikrer at brukeridentiteter og gruppemedlemskap opprettholdes konsekvent på tvers av miljøet ditt.

For organisasjoner som implementerer trinnvise distribusjoner, er det avgjørende å kontrollere og begrense omfanget av synkronisering under første utrulling. Dette minimerer risikoen for utilsiktede endringer og gir mulighet for målrettet testing før bredere adopsjon.

Den mest effektive metoden for å filtrere hvilke brukere som synkroniseres, er å utnytte kataloggruppemedlemskap:

1
Opprett en dedikert synkroniseringsgruppe: I bedriftskatalogen (Microsoft Entra ID eller AD) oppretter du en sikkerhetsgruppe spesielt for synkronisering (for eksempel synkroniseringsgruppe).

2
Fyll gruppen med målbrukere: Legg bare til brukerne du vil synkronisere (for eksempel en testgruppe under pilotfasen) i denne gruppen. Dette lar deg kontrollere hvem som er inkludert i synkroniseringsprosessen tett.

3
Konfigurer synkroniseringsavtalen med gruppebasert filtrering: Når du konfigurerer synkroniseringsavtalen i Directory Connector eller Entra ID-klargjøring, konfigurerer du omfanget slik at det bare inkluderer brukere som er medlemmer av den angitte gruppen.

For Microsoft Entra ID kan du bruke gruppebaserte tildelinger i klargjøringsinnstillingene

For AD kan du definere et LDAP-filter som bare inkluderer brukere som tilhører den angitte gruppen.

4
Utvid gruppen etter behov: Når du går videre til bredere distribusjonsfaser, legger du bare til flere brukere eller grupper i synkroniseringsgruppen. Synkroniseringsomfanget utvides automatisk til å omfatte disse brukerne, noe som muliggjør kontrollert og gradvis utrulling.

Eksempel på implementeringstrinn:

I aktiv katalog:

Opprett en sikkerhetsgruppe med navnet synkroniseringsgruppe.

Legg til ønskede pilotbrukere i denne gruppen.

Sett opp Directory Connector med et LDAP-filter som: (MemberOF=CN=WebEx Sync Group, OU = Groups, DC=Ditt domene, DC=COM).

I Microsoft skriver du inn ID:

Opprette en gruppe med navnet synkroniseringsgruppe

Tilordne gruppen til klargjøringsinnstillingene i Entra ID

Bare brukere i denne gruppen vil bli klargjort til.

Test alltid gruppebasert synkronisering i et ikke-produksjonsmiljø før du søker på hele organisasjonen

Gjennomgå gruppemedlemskap regelmessig for å sikre at bare autoriserte brukere synkroniseres

For løpende administrasjon kan du automatisere oppdateringer av gruppemedlemskap basert på forretnings regler eller HR-systemer hvis mulig.

Referanser:

Synkroniser Entra ID-brukere til Control Hub

Konfigurere veiviserappen Entra ID i Control Hub

Katalogkontakt

Konfigurere og teste Single Sign-On (SSO)

Single Sign-On (SSO) forbedrer sikkerheten og forenkler brukertilgangen ved å la brukerne autentisere én gang med bedriftens legitimasjon og få sømløs tilgang til. støtter SSO-integrasjon med SAML 2.0-kompatible IDP-er, inkludert Microsoft Entra ID (tidligere Azure AD), Active Directory (AD) fødererte løsninger og ulike tredjeparts IDP-er.

På dette tidspunktet bør det designede SSO-oppsettet implementeres og testes.

Referanser:

Enkel påloggingsintegrasjon i kontrollhuben

konfigurere enkel pålogging for webex-administrasjon

Konfigurer enkel pålogging med Microsoft Entra ID

SSO med flere IDP-er

Administrer SSO ved integrering i Control Hub

Anskaffe, levere og verifisere lisenser

Som en del av det første oppsettet for, er det viktig å skaffe, klargjøre og verifisere de riktige lisensene for å aktivere og administrere tjenester effektivt. Innkjøpsprosessen innebærer å velge lis enstyper basert på brukerroller og arbeidsbelastninger, for eksempel Professional-, Standard- og Workspace- lisenser. Lisenser genereres og leveres gjennom Ciscos programvareplattformer eller gjennom partnere. Etter anskaffelse og klargjøring må riktige lisenstall verifiseres i. Denne prosessen sikrer at organisasjonen har de riktige lisensene aktivert og klar til bruk i distribusjonen.

Som en del av det første lisensieringsoppsettet i, er det viktig å konfigurere organisasjonsbasert automatisk lisensiering for å effektivisere lisenstildeling for nye brukere. Dette oppsettet gjør det mulig å gi lisenser automatisk når brukere legges til i organisasjonen, noe som eliminerer behovet for manuell lisenstil deling. Når du konfigurerer automatisk lisensiering på organisasjonsnivå, velger du tjenestene som skal tilordnes og definerer omfanget, for eksempel å bruke lisenser bare på fremtidige brukere eller inkludere eksisterende brukere også.

Hvis distribusjonsplanen innebærer bruk av automatisk lisensiering på gruppenivå i stedet, kan du imidlertid velge å ikke tilordne lisenser på organisasjonsnivå for å unngå konflikter eller dupliserte lisenstildelinger. Med automatisk lisensiering på gruppenivå tildeles lisenser basert på gruppemedlemskap. Brukere i flere grupper mottar lisenser fra alle gjeldende gruppetildelinger.

Gruppebasert lisenstildelingskonfigurasjon må utføres etter at katalogsynkroniseringen er fullført, slik at synkroniserte grupper eksisterer og kan brukes til lisenstildeling.

Spesielt krever automatisk lisenstildeling ytterligere klargjøringsdetaljer, for eksempel brukerplassering og tildeling av telefonnummer. Brukerens arbeidstelefonnummer må være i +E.164-format, forhåndsbestemt og tilordnet et gyldig sted for at lisensen skal aktiveres automatisk. Hvis disse betingelsene ikke er oppfylt, vil brukeren ikke få tjenester automatisk, og det kan kreve manuell inngrep.

Oppsummert kan du konfigurere organisasjonsbasert automatisk lisensiering for nye brukere hvis du vil ha en bred lisenstilordning for hele organisasjonen. Hvis du foretrekker mer detaljert kontroll eller har forskjellige lisensieringsbehov per gruppe, kan du konfigurere automatisk lisensiering på gruppenivå og unngå å tilordne lisenser på organisasjonsnivå for å forhindre overlapping og sikre riktig lisensadministrasjon.

Webex Callingtjenesteinnstillinger

Det er viktig å gjennomføre en omfattende gjennomgang og konfigurasjon av de globale tjeneste innstillingene innenfor.

Begynn med å gå til og navigere til innstillingsdelen. Undersøk nøye hvert konfigurerbart alternativ, inkludert, men ikke begrenset til, intern oppringingingskonfigurasjon, nødanropsparametere, samtalerutingspolic yer, talepostadministrasjon og standardinnstillinger for enheten.

Juster disse globale innstillingene slik at de gjenspeiler organisasjonens retningslinjer og designbeslutninger.

Også, oppsettinnstillinger og bruker- og appmaler.

Pilotmigrasjon

I implementeringsfasen representerer gjennomføring av en pilotmigrering en kritisk milepæl i valideringen av overgangen fra til. Denne piloten innebærer å klargjøre et representativt delsett av brukere på tvers av ett eller flere steder på plattformen, og sikre at den valgte populasjonen gjenspeiler forskjellige brukstilfeller og organisatoriske roller. Parallelt med brukermigrering må viktige samarbeidstjenester, inkludert telefonsvarer, automatiske svartjenester, samtalekøer og jaktgrupper, overføres til sine ekvivalenter for å opprettholde forretningskontinuitet og tjenestefunksjonalitet.

Pilotmigreringen bør utnytte den samme kombinasjonen av Cisco-leverte verktøy og tredjepartsmigreringsverktøy som er planlagt for den bredere organisasjonsdistribusjonen, og sikre at prosessene, automatiseringsarbeidsflytene og integrasjonspunktene blir grundig validert under representative forhold.

Hovedmålene for denne pilotdistribusjonen er todelt: For det første, å validere og finjustere ende-til-ende-overgangsprosess ene, inkludert arbeidsflyter for klargjøring av brukere, prosedyrer for datami grering, og endepunktkonfigurasjoner; og for det andre, å fullstendig verifisere funksjonaliteten til migrerte tjenester under virkelige driftsforhold.

Denne trinnvise tilnærmingen gjør det mulig for prosjektteamet å identifisere og løse eventuelle tekniske eller prosessuelle problemer i et kontrollert miljø, samle tilbakemeldinger fra brukerne om den nye plattformopplevelsen, vurdere effektiviteten til utvalgte migr eringsverktøy og etablere tillit til migreringsm etodikken før de fortsetter med bredere organisatorisk distribusjon.

Innsikten som er oppnådd i løpet av denne pilotfasen er avgjørende for å optimalisere påfølgende migrasjonsbølger og sikre en jevn, risikoredusert overgang for hele bedriften.

Anskaffe PSTN

For å anskaffe PSTN-tjenester for, velg først et PSTN-tilkoblingsalternativ i.

Hvis en organisasjon planlegger å opprettholde hybrid dobbel samtalekontroll (fase 1 i figur Faset an ropsovergang: Hybrid og sky) enten midlertidig eller på ubestemt tid, må de distribuere en eller flere lokale gateways for lokalt PSTN for å tillate anrop mellom og endepunkter.

Hvis en full overgang (fase 2) til skyen er sluttmålet inkludert PSTN, vil enten en Cisco Calling Plan eller et Cloud Connect for alternativ være nødvendig for PSTN.

Arbeid med den valgte leverandøren for å bestille og portere telefonnumre før du konfigurerer dem inn. Bestilling av telefonnumre eller initiering av portbestillinger er bare nødvendig/mulig for lokal PSTN og Cloud Connect for. For Cisco-samtaleplaner startes bestilling og portering fra Control Hub så snart lokasjonen er opprettet, og i land der Cisco Calling Plan er tilgjengelig. Hvis du vil ha mer informasjon om Cisco Calling-planer, kan du se Komme i gang med Cisco-abonnementene.

Som en del av PSTN-implementeringen må du sørge for at leverandøren din har aktivert både innkommende og utgående PSTN-tjenester for posisjonen din. I tillegg kan du utføre testanrop for å bekrefte at samtaler blir rutet riktig gjennom den valgte PSTN-tilkoblingen.

Konfigurer plasseringer

Før du legger til brukere og enheter i, må du klargjøre anropssteder. For hvert sted må en gyldig gateadresse oppgis. I USA og Canada valideres denne adressen og brukes av plattformen til å sende PIDF-LO-posisjonsinformasjon for nødanrop.

Når du konfigurerer lokasjoner som bruker lokal PSTN, må du konfigurere de lokale gatewayene tilsvarende. I må en stamme og en rutegruppe opprettes for hver lokal gateway, og rutegru ppen tilordnes deretter som PSTN-valget for plasseringen. Cisco anbefaler på det sterkeste at du alltid velger en rutegruppe som PSTN-valg, da denne tilnærmingen lar deg enkelt legge til flere trunker i fremtiden, som støtter både skalerbarhet og redundans. Cisco anbefaler også å aktivere dual-identity og P-Charge-Info-støtte på alle PSTN-trunker, siden dette forenkler identifiseringen av den fakturerbare parten for utgående direkte eller omdirigerte samtaler. Hvis PSTN-leverandøren bruker en annen overskrift for fakturering, kan du kopiere informasjonen fra P-Charge-Info-overskriften på den lokale gatewayen til den nødvendige faktureringsoverskriften.

For steder som bruker Cloud Connect for eller Cisco Calling Plan som sitt PSTN-alternativ, velger du ganske enkelt det respektive PSTN- valget for stedet under oppsettet. Hvis plasseringen bruker enten Cloud Connect for eller lokal PSTN, må du legge til telefonnumrene som ble bestilt i forrige trinn. Numre kan legges til som inaktive hvis du ikke vil at de skal inkluderes i samtal erutingen med en gang; du kan aktivere disse numrene senere når de tilordnes brukere eller funksjoner.

Det er viktig å alltid angi hovednummeret for hvert sted. Hovednummeret kan tilordnes enten en bruker eller en funksjon, for eksempel en automatisk ledsager. For å aktivere talepost på stedet, må du sørge for å angi telefon svarerpilotnummeret, også kjent som taleportalnummeret.

Ytterligere innstillinger for anropssteder inkluderer konfigurering av nødanropdetaljer, for eksempel nødnummeret, varsling salternativer og forbedrede nødanropsfunksjoner. Du bør også se gjennom og justere opptaksinnstillinger, språkpreferanser og enhet skonfigurasjoner etter behov for hvert sted. Hvis organisasjonen bruker forkortet internett-oppringing med betydelige virksomhets numre, må du huske å konfigurere en unik områdekode for stedet i de interne oppringingsinnstillingene. Til slutt, hvis ekstern oppringing krever et utgående nummersiffer, må du sørge for å angi dette i innstillingene for ekstern oppringing. Når et utgående nummersiffer er konfigurert, anbefaler Cisco å aktivere håndhev ing av utgående nummersiffer for å sikre konsistens.

Integrasjon med lokal samtalekontroll

Hvis du vil integrere med lokal anropskontroll, er det nødvendig å konfigurere trunker, rutegrupper, bedriftsoppringingsplaner og både lokasjonsinnstillinger og globale innstillinger. Begynn med å sette opp trunkene og de lokale gatewayene som er beregnet for sammenkobling med det lokale anropskontrollsystemet. Dette trinnet er bare nødvendig hvis dedikerte trunker er nødvendige. Hvis eksisterende trunker og rutegrupper er tilstrekkelige for distribusjonen, kan de brukes på nytt for den lokale sammenkoblingen uten ytterligere konfigurasjon.

Når stammene og rutegruppene er etablert, fortsetter du med å opprette virksomhetsnummerplanene og tilordne den aktuelle rutegruppen som destinasjon for hver nummerplan. Når integrering involverer flere lokale anropskontrollsystemer koblet gjennom forskjellige trunker, vil det være nødvendig med flere oppringingsplaner. Det er viktig å sikre at disse nummerplanene bare inneholder mønstrene som er nødvendige for å dirigere anrop til lokale destinasjoner.

Hvis distribusjonen krever støtte for ukjent utvidelsesruting, bør denne funksjonen være aktivert på stedsnivå. I tillegg, når ukjent utvidelsesrut ing er aktivert, må du angi maksimal ukjent forlengelseslengde i delen An ropsruting mellom og lokaler i innstillingene for anropstjenester i. Dette sikrer sømløs samtaleruting og riktig håndtering av utvidelsesbaserte oppringings scenarier i ditt integrerte miljø.

Overfør brukere i grupper

Når du overfører brukere fra til, kan du kanskje ikke flytte alle brukere samtidig. Dette kan skyldes flere årsaker, inkludert, men ikke begrenset til, antall nettsteder eller brukere, hvor lang tid det tar å overføre et nettsted og/eller en gruppe brukere på en gang, begrenset IT- eller nettstedsressurs for å støtte endringsvinduet, varigheten av endringsvinduet, endringens kompleksitet osv.

Når du overfører brukere i faser, er det viktig å identifisere hvilke brukere som må migrere sammen i samme batch. Det primære målet er å migrere brukere sammen som har avhengigheter med hverandre for sine samtaletjenester og funksjoner. Du vil sikre at alle samtal efunksjonene deres (Eksempel - Anropskøer) er fullt funksjonelle på som de var før overgangen på.

Selv om du implementerer samtalesamarbeid mellom og med lokale gateways, kan du ikke dele delte tjenester eller funksjoner på tvers av denne tilkoblingen. Derfor må du identifisere avhengighetene mellom brukere ved å se på funksjoner som:

Overvåke andre brukere som bruker BLF-er

I samme jaktpilot, anropskø osv

Delte linjer

Bruke henting av anrop

Bruke de samme telefonnummerene

Intercom

Eksekutiv/Administrator.

Et eksempel kan være en bruker som er en del av en Hunt Group som blir overført til. Denne brukeren vil gå over til med Hunt Group og med alle andre medlemmer av Hunt Group. Derfor, etter overgangen kan Hunt Group og dets medlemmer lykkes med å svare på samtaler på den nye plattformen.

Dette blir mer utfordrende når brukere er koblet til forskjellige grupper av brukere for forskjellige samtaletjenester og funksjoner. Dette vil kreve overgang av mer enn én gruppe brukere og en ringetjeneste til samtidig.

Bruk utdataene fra Migreringsinnsiktsverktøyet eller tredjepartsverktøyet du brukte i forberedelsesfasen til å bestemme hvilke brukere og funksjoner som skal grupperes sammen. Denne utgangen skal ha blitt brukt til å utvikle overføringsplanen din, og vil gi deg innsikt i hvordan du vil gruppere brukere og funksjoner som trenger å gå over sammen.

De viktigste trinnene når du overfører en gruppe brukere er:

Identifisere brukere som skal migreres sammen

Bekreft at alle brukere er inne

Bekreft at alle TN-er for brukerne finnes i

Bekreft riktig telefonnummerformat i katalogen

Kontroller at lisensierings- og innstillingsmalen for brukergruppene er riktig konfigurert

Verifisere eller konfigurere alle anropstjenester og funksjoner for bruker gruppen (før eller under overgangen etter behov)

Legg til brukere i gruppen av anropsaktiverte brukere i bedriftskatalog en

Utnytte verktøy - bruker- og funksjonsmigreringsverktøy og/eller tredjepartsverktøy

Deaktiver/slett bruker-/enhetskatalognummer og anropsfunksjoner/tjenester på etter overgangen.

Når du har overført en gruppe brukere, tester du et delsett av brukerne for å bekrefte at alle anropsfunksjonene og tjenestene deres fungerer som de skal. Hvis anropsfunksjoner som samtalekø, jaktgrupper osv. overføres med gruppen av brukere, må du teste disse anropstjenestene for riktig funksjonalitet.

Arbeidsområder

I refererer et arbeidsområde til et delt sted (for eksempel et konferanserom, møteplass eller hot desk) som kan tilordnes enheter, utvidelser og brukere. I motsetning til tradisjonelle Unifed CM- telefoner, er arbeidsområder:

Plasseringssentrisk: bundet til fysiske rom.

Enhetsfleksibel: kan ha en eller flere enheter (skrivebordstelefoner, tavler, etc.).

Når arbeidsområder er identifisert som en del av overgangen til, kan de legges til under Enheter. Hvert arbeidsområde trenger en enhetstilordning, og hvis de allerede er inneUnified CM, må de tilbakestilles eller klargjøres på nytt. funksjoner som telefonsvarer, viderekobling og henting av anrop kan aktiveres eller deaktiveres, og retningslinjer kan brukes for videosamtaler, anropsparkering og mobilitet etter behov. Test hvert arbeidsområde ved å ringe interne og eksterne samtaler, teste video-, konferanse- og mobilitets funksjoner. Til slutt, gi brukerne beskjed om eventuelle gjeldende prosesser for arbeidsområdeenheter og bestillinger.

Hvis du vil ha mer informasjon om arbeidsområder i, kan du se Arbeid sområder.

Tilveiebringsenheter

Telefoner som for øyeblikket er registrert på, må migreres til som en del av skyovergangen. For å gjøre migreringen så enkel som mulig med minimal sjanse for feil, anbefaler Cisco å migrere fysiske nettsteder eller avdelinger samtidig. Det kan imidlertid hende du må migrere brukere i grupper på grunn av funksjonsavhengigheter. Se avsnittet Over føre brukere i grupper for mer informasjon.

Alle støttede telefoner som du trenger å gå over fra, må konfigureres som bruker eller arbeidsområde, og den fysiske telefonen må konfigureres på nytt for å registrere deg med . I tillegg trenger telefonene i 7800- og 8800-serien sin firmware oppgradert fra Enterprise- firmware til Multiplatform Phone (MPP) firmware. Denne prosessen inkluderer lasting av overgangs firmware før du laster inn MPP-fastvaren som kreves for registrering. Det krever også riktig migrasjonslisens. Cisco har forbedret denne prosessen de siste årene for å gjøre det lettere for deg å oppgradere Enterprise-firmwaretelef oner til MPP-firmware. Hvis du vil ha mer informasjon om trinnene for å fullføre fastvareoppgraderingen, kan du se Konvertere IP-telefoner i Cisco 7800- og 8800-serien mellom Enterprise- og MP P-fastvare.

I tillegg til trinnene som er beskrevet i denne artikkelen, har du et innebygd verktøy, Overfør telefonen til Webex Calling, som du kan bruke til å migrere 7800- og 8800-telefonene fra Enterprise til MPP-fastvare. Dette verktøyet lar deg også legge telefonene til og tilordne dem til de aktuelle brukerne eller arbeidsområdene. Hvis du vil ha mer informasjon om verktøybruk, kan du se Overføre telefonen.

For telefoner i 9800-serien som er registrert med ovennevnte fastvaremigreringskrav gjelder ikke. Disse telefonene kjører PhoneOS, som støttes av både og. For å overføre disse telefonene til, må du legge dem tilWebex Calling, tilordne dem til en bruker eller et arbeidsområde og deretter tilbakestille telefonene til fabrikken. PhoneOS-oppstartssekvens for registrering Figur nedenfor viser oppstartssekvensen for PhoneOS og hvordan telefonen vil registrere seg når den er blitt lagt til, selv om telefonen fremdeles er klargjort og/eller DHCP-alternativer (Eksempel - 150) er i bruk.

PhoneOS oppstartssekvens for registrering

støtter fabrikkinnstilling av PhoneOS-enheter for å tillate Zero-Touch-onboarding til. administratorer kan eksternt tilbakestille 9800- og 8875-telefonene via CUCM-administrasjons sidene, noe som eliminerer behovet for fysisk tilgang til telefonene for å ombord telefonene til. Denne funksjonen støttes med enhetspakkene fra 9. september 2025:

CUCM v15 — Unified Communications Manager versjon 15

CUCM v14 - Unified Communications Manager versjon 14.

For mer informasjon om registreringsprosessen for 9800-serien, se Registrerings prosess.

I tillegg til Cisco IP-telefoner, kan det være nødvendig med klargjøring av andre enheter som analoge telefon adaptere (ATA), trådløse (Wifi, DECT) telefoner, videoenheter, stemmegateways og tredje ^part senheter og -telefoner. Mange av disse enhetene har ikke en fastvareoppgraderingsbane som IP-telefonene for å overføre dem fra bedriftsfirmware til sky fastvare. Derfor vil du klargjøre hver av disse enhetene i Control Hub. Noen av disse kan ikke overføres til, og den tilsvarende modellen må erstatte den (f.eks. ATA 191/192) og andre vil kreve manuell rekonfigurasjon og/eller programvareendringer.

Talegatewayer — Hvis du vil migrere den lokale gatewayen, kan du se Overføre lokal gateway.
Hvis du vil ha mer informasjon om hvordan du konfigurerer talegatewayen VG400, VG410 eller VG420 i Control Hub, kan du se Lokal gateway

Analog telefonadapter (ATA) - For å komme i gang med Cisco ATA 191 og 192, se Cisco ATA.

Trådløs Wifi-telefon - Hvis du vil integrere trådløs telefon 840 og 860, kan du se Integrere trådløs Webex telefon.

Trådløse DECT-telefoner - For å komme i gang med den nye Cisco IP DECT 6800-serien, se Cisco IP DECT.

Hvis du vil bygge og administrere digitalt DECT-nettverk i Control Hub, kan du se Administrer DEC T-nettverk

Hvis du vil ha mer informasjon om Cisco IP DECT 6800, kan du se Implementeringsveiledning

Tred ^je partsenheter og -telefoner - Arbeid med tredje ^part sleverandører om krav til enhet/telefon og prosessen for å migrere eller erstatte dem for å støtte.

Konfigurer funksjoner

Eventuelle anropsfunksjoner som kreves må klargjøres før eller under overgangen. Som diskutert i delen Overfør brukere i grupper, må anropsfunksjonene konfigureres og overføres når brukerne som bruker dem blir overført.

Hvis du vil ha mer informasjon om hvordan du konfigurerer hver av funksjonene, kan du se de tilsvarende hjelpeartiklene for konfigurasjon.

Automatiske svartjenester — Hvis du vil administrere automatiske svartjenester, kan du se Automatiske svartjenester

Anropsparkering - Hvis du vil administrere anropsparkering, kan du se An rop sparkering

Henting av anrop — Hvis du vil konfigurere gruppen for henting av anrop, kan du se H enting av anrop

Anropskøer — Hvis du vil konfigurere anropskø, kan du se An rop skø

Jaktgrupper — Hvis du vil administrere jaktgrupper, kan du se Administrer jakt gruppe

Driftsmoduser — Hvis du vil ringe ruting basert på driftsmoduser, kan du se Anropruting basert på driftsmoduser

Personsøkingsgrupper — Hvis du vil konfigurere en personsøkingsgruppe, kan du se Konfigurere en personsøkingsgruppe

Opptak — Hvis du vil administrere anropsopptak for, kan du se Administrer opptak

Enkeltnummerrekkevidde — Hvis du vil konfigurere enkeltnummerrekkevidde (kontor hvor som helst), kan du se Konfigurere enkeltnummer

Talepostgruppe — Hvis du vil administrere en delt talepost og en innkommende faksboks for, kan du se Administrere telefonsvarer.

Godkjenningstesting

Godkjenningstesting sikrer at det migrerte miljøet oppfyller funksjonskravene, fungerer som forventet, og leverer en sømløs brukeropplevelse på tvers av alle kommunikasjonsarbeidsflyter. Denne validerings prosessen er mangesidig, og dekker alt fra brukerklargjøring og nummertildelinger til den operative ytelsen til avanserte anropsfunksjoner.

Denne delen gir eksempler og fremhever viktige aspekter å vurdere under aksepttesting; men, det er ikke ment å tjene som en uttømmende eller omfattende sjekkliste.

Brukerklargjøring og nummertildeling

Et grunnleggende aspekt ved aksepttesting innebærer å verifisere at alle brukere er klargjort nøyaktig og fullstendig innenfor. Dette krever en grundig sammenligning mellom source () -katalogen og den nylig etablerte brukerbasen for å sikre at hver brukerkonto, sammen med tilknyttede attributter som ut videlsesnumre og DID-tildelinger (Direct Inward Dial), er blitt korrekt migrert. Fullstendighet av klargjøring er avgjørende, ikke bare for drift fra dag én, men også for lø pende administrasjon og støtte.

Validering av nummertildeling inkluderer bekreftelse av at hver bruker er tildelt riktig utvidelsesnummer og eksternt nummer, og at disse tallene ruter riktig i både interne (på nett) og eksterne (PSTN) anropsflyter. Det er viktig å se etter eventuelle overlappinger, manglende tildelinger eller feilkonfigurasjoner som kan føre til anroprutingsfeil eller tjenesteavbrudd.

PSTN Anropsflyt og presentasjon av anrops-ID

En robust aksepttestprosedyre må omfatte ende-til-ende- validering av PSTN-anropsflyter. Dette inkluderer både innkommende og utgående anropsscenarier . For innkommende PSTN-anrop bør testteamet bekrefte at anrop leveres til de tiltenkte endepunktene, enten dette er individuelle brukere, samtalekøer, jaktgrupper eller automatiske svarmenn. Utgående PSTN-anrop må plasseres vellykket, med spesiell oppmerksomhet gitt til riktig levering og presentasjon av innringer-ID-informasjon. Dette innebærer å sikre at riktig innringernavn og nummer vises til eksterne mottakere, i samsvar med organisasjonspolitikk og for skriftskrav.

Testing bør også adressere failover-scenarier, for eksempel håndtering av util gjengelige endepunkter eller nettverksforstyrrelser. Dette bidrar til å bekrefte at fallback-mekanismer og alternativ ruting fungerer som de skal, og oppret tholder tjenestekontinuitet og pålitelighet.

Anropsstrømmer på nettet

Interne eller nettbaserte samtaleflyter danner ryggraden i bedriftskom munikasjon. Godkjenningstesting i dette området bekrefter at samtaler mellom brukere i organisasjonen rutes riktig, med funksjoner som overføring av anrop, hold, videresending og konferanser som fungerer som beregnet. Integriteten til oppringingsplaner, tilkoblingsmuligheter for utvidelse til utvidelse og støtte for retningslinjer for organisasjonsan rop må bekreftes.

Brukersamtalehåndtering og funksjonsvalidering

Et viktig aspekt ved aksepttesting innebærer å validere hvordan brukere håndterer samtaler ved hjelp av og støttede skrivebordstelefoner. Denne prosessen fokuserer på å bekrefte at daglige samtalearbe idsflyter er intuitive og pålitelige, og at brukerne har sømløs tilgang til kjerne funksjonene som er nødvendige for rollene deres. Testing bør vurdere hvor enkelt brukere kan ringe og motta samtaler, administrere hold- og gjenopptaksfunksjoner, og utføre både blinde og rådgivende overføringer. Det er også viktig å verifisere at viderekobling, konferanse og andre avanserte funksjoner, for eksempel parkering og hente samtaler eller aktivere ikke forstyrr, er lett tilgjengelige og fungerer problemfritt.

Opplevelsen bør evalueres for klarhet og respons, med tanke på hvordan brukere samhandler med samtalelogg, telefonsvarer og integrerte kataloger. Ytterligere oppmerksomhet bør rettes mot muligheten til å flytte aktive samtaler mellom enheter og å bruke samtalekontroller effektivt i applikasjonen eller på fysiske telefoner. Det endelige målet er å sikre at sluttbrukeropplevelsen er konsistent, effektiv og fullt ut støtter organisasjonens kommunikasjonsbehov etter migreringen.

Samtalekøer: Agent- og veiledererfaring

Anropskøer brukes ofte til å håndtere scenarier for inngående samtaler med høyt volum. Godkjenningstesting her fokuserer på flere dimensjoner. Først bør det verifiseres at anrop distribueres til agenter i henhold til den konfigurerte kølogikken, slik som round robin, lengst tomgang eller samtidig ring. Presentasjonen av anrop i kø på agent skrivebord må undersøkes for klarhet og brukervennlighet, slik at agenter effektivt kan godta, holde og overføre samtaler.

For veiledere bør skrivebordsopplevelsen evalueres for funksjoner som sanntidsovervåking, samtalefarging og analyse eller inn sikt i køytelse. Dette inkluderer, men er ikke begrenset til, validering av dashbord og rapporteringsverktøy som gir handlingsbare data om samtalefor deling, agentaktivitet og køberegninger.

Jaktgrupper: Samtalefordeling

Jaktgrupper er en nøkkelmekanisme for å distribuere samtaler til forhåndsdefinerte sett med brukere. Godkjenningstesting må bekrefte at anrop rutes til gruppemedlemmer basert på den konfigurerte jaktalgoritmen, og at overløp, videresending, og no-svar scenarier håndteres i henhold til design. Å sikre at gruppemedlemskap og samtalerutingsatferd samsvarer med de som tidligere er etablert i, er avgjørende for operativ konsistens og brukertilfredshet.

Autorespondenter: Kunngjøringer og menyoperasjoner

Autorespondenter representerer frontlinjen for automatisert samtalehåndtering. Testing må dekke avspilling av kunngjøringer, nøyaktigheten av inn spilte hilsener og riktig drift av menytrær. Meny valg skal på en pålitelig måte rute innringere til de aktuelle avdel ingene, enkeltpersoner eller eksterne numre. Testing bør også omfatte ugyldige scenarier eller tidsavbruddsscenarier for å bekrefte at innringere får tydelig veiledning eller blir omdirigert som beregnet.

Talepostoperasjon

Til slutt er telefonsvarerfunksjonalitet avgjørende for brukeropplevelsen. Godkjenningstester bør bekrefte at telefonsvarerbokser er riktig tilordnet og tilgjengelige, både fra organisasjonen og eksternt. Muligheten til å registrere, hente og administrere meldinger må bekreftes, sammen med varsellevering.

Optimaliser

PSTN-migrering til Cloud Connect for

Optimaliser lokal infrastruktur

Bruk analyser og feilsøking

PSTN-migrering til Cloud Connect for

Når alle endepunkter og brukere er migrert til skyanrop, Unified CM er det eneste formålet med å fungere som en transitt mellom PSTN-gatewayene og via lokal gateway. Å fjerne PSTN-gateways,, og Local Gateway fra bildet ved å bruke Cloud Connect for som PSTN-tilgang for alle Webex Calling brukere, har flere fordeler, inkludert kostnads reduksjon og forbedret pålitelighet. Følg disse trinnene for å overføre lokal PSTN-tilgang til Cloud Connect for :

Cloud Connect for partnervalg.

Se listen over Cloud Connect for partnere, og velg blant de tilgjengelige partnerne som er tilgjengelige for organisasjonens beliggenhet.

Cloud Connect for validering.

Før du bytter PSTN-tilgang for lokasjoner til Cloud Connect, bør tilkoblingen til PSTN via den valgte Cloud Connect-partneren verifiseres og valideres. For dette formålet må en testplassering klargjøres med noen testbrukere klargjort på den testplasseringen. PSTN-tilgang for dette test stedet settes deretter til Cloud Connect-partneren før du validerer PSTN-tilkobling ved hjelp av testtelefonene. Etter vellykket validering kan testplasseringen avklares.

Nummerportering.

For å forberede overgangen til Cloud Connect, må det legges inn en portordre for alle numre som for øyeblikket er tildelt PSTN-stammen som avsluttes. Alle numre må overføres til Cloud Connect-partneren. For å opprettholde tilgjengeligheten mellom lokasjoner, må alle antall av alle lokasjoner porteres samtidig .

Bytt til Cloud Connect-partner.

På datoen for overgangen må PSTN-tilgang for alle lokasjoner i settes til Cloud Connected PSTN-leverandøren, og innkommende og utgående tilkobling bør verifiseres.

Som diskutert i PSTN-delen av designkapittelet, kan kunder også velge å flytte PSTN-tilgangen til Cloud Connect for i starten av overgangen ved å bruke PSTN-trunking for hybriddistribusjoner. Hvis du vil ha mer informasjon, kan du se PSTN-trunking for hybriddistribusjoner. Webex Calling I dette tilfellet under overgangen er PSTN-tilgang for via lokal gateway, og etter at alle brukere er flyttet til, er det ikke noe ytterligere PSTN-relatert migreringstrinn annet enn avvikling og de lokale gateway-ene.

Optimaliser lokal infrastruktur

Når alle brukere har blitt overført til og alle endepunkter har blitt overført til skyregistrering (eller er tatt ut av drift), oppdat erer du passende lokal infrastruktur nå som skyanrop er i bruk. Oppdateringer av infrastrukturen inkluderer:

Fjern lokale anropskontroll- og meldings DNS SRV oppføringer fra den lokale DNS-serveren (e), inkludert cisco_uds. _tcp. <domain>, cup_login. _tcp. <domain>. Disse SRV-postene er ikke lenger nødvendige for oppdagelse av klienttjenester.

Fjern kantrelaterte DNS SRV poster fra det offentlige DNS-systemet inkludert collab_edge. _tls. <domain>. Disse SRV-postene er ikke lenger nødvendige for klienttjenesteoppdagelse av kant tjenester for samarbeid.

Oppdater alle relevante DHCP-områder for å fjerne alternativ 66 og alternativ 150 TFTP/oppstartsserveradresser. Disse omfangene er ikke lenger nødvendige for oppdagelse og nedlasting av konfigurasjon for endepunktsamtalekontroll.

Oppdater/fjern passende oppringingingere i Lokal gateway/kube som dirigerer anrop til og fra. Unified CM Disse oppringingsjevnaldrende er ikke lenger nødvendige for lokal samtaleruting.

Slett eller fjern alle virtuelle maskiner og/eller servere i klyngenode. Bruk beregningsressurser og maskinvare på nytt etter behov. Disse ressursene er ikke lenger nødvendige for anropskontroll og kanttjenester.

Slett eller fjern alle virtuelle maskiner og/eller servere i klyngenode. Bruk beregningsressurser og maskinvare på nytt etter behov. Disse ressursene er ikke lenger nødvendige for telefonsvarer og enhetlige meld ingstjenester.

Opprydding: Etter migrering av PSTN-tilgang til Cloud Connected PSTN, kan PSTN-trunker, PSTN-gateways og Local Gateway tas ut av drift.

For alle eksisterende lokale E911-løsninger sletter du alle plasseringer eller numre som har migrert til, og når full overgang er fullført, fjerner du virtuelle programmaskiner eller servere. Bruk beregningsressurser og maskinvare på nytt etter behov. Disse ressursene er ikke lenger nødvendige for nødanrop og lokaliseringstjenester.

DNer som tilhører migrerte brukere bør plasseres i en skjult partisjon for å unngå feil i samtalerutingen og for å sikre at alle CSS-er har prioritert tilgang til skybanen til de samme DNene.

Oppdater den fysiske forsendelsesbare plasseringen og nettverkselementet i horisontmobilitet når endringer skjer. Vanlige aktiviteter som krever oppdateringer er:

Utskifting av nettverksbryter

Utskifting av trådløst tilgangspunkt

Endringer i DHCP-omfang

Fysiske endringer inne i bygningen (hvis det løses til kubikal/kontor)

Fysisk utvidelse eller sammentrekning av kontorlokaler inne i en bygning.

Bruk analyser og feilsøking

gir omfattende analyse- og feilsøkingsfunksjoner for å hjelpe deg med å visualisere og spore distribusjonen. Disse dekker mediekvalitet, detaljert samtalelogg, samtalekø, jakt gruppe, og automatisk svarteanalyse. Et eksempel på mediekvalitetsanalyse er vist i figur mediekvalitetsanalyse.

analyse av mediekvalitet

Under feilsøking kan hvert anrop som gjøres ved hjelp av vises med detaljert informasjon om viktige mediekvalitet og signalrelaterte problemer for å finne medieproblemer så vel som mislykkede anrop, som vist i feilsøking av medi ekvalitet på figuren.

feilsøking av mediekvalitet

Feilsøking kan også integreres med andre Cisco-produkter som ThousandEyes og Meraki- svitsjer for å gi en enda rikere integrert opplevelse i Control Hub. Hvis du vil ha mer informasjon om bruk av Webex Callinganalyser og feilsøking, kan du se Feilsøke an Webex Calling rop i Control Hub.

Introduksjon

Før du begynner

Oversikt

Kjernekomponenter

PPDIO prosessoversikt

Generell beskrivelse av PPDIO

Bruke PPDIO for Unified CM å Webex Calling migrere prosjekter

Forberede

Planlegg

Utforming

Implementere

Optimaliser

PPDIO tilbakemeldingssløyfer

Migrasjonstilnærming

Før du begynner

Denne veiledningen er ment for team eller enkeltpersoner med erfaring med å konfigurere og administrere Cisco Unified Communications Manager (Unified CM) og Cisco-endepunkter, inkludert IP-skrivebordstelefoner, videoenheter, og Jabber-myke klienter. Gjennom dette dokumentet er det lenker til produkt- og støttedokumentasjon for å hjelpe deg.

Dette dokumentet fokuserer bare på overganger fra Unified CM til Webex Calling flerleietaker. Begrepet Webex Callingi dette dokumentet refererer alltid til Webex Calling flerleietaker.

Før du begynner migreringen fra Unified CM tilWebex Calling, er det viktig å ha en omfattende forståelse av Webex Calling løsningen og dens respektive komponenter. En vellykket migrering krever kjennskap til Webex Calling arkitek turen, tjenestemodellene, distribusjonsalternativene og tilknyttede funksjoner for å kartlegge eksisterende Unified CM arbeidsbelastninger riktig og utforme en effektiv overgangsplan.

En grundig forståelse av følgende Webex Calling komponenter er avgjørende for å informere om en effektiv overgangsstrategi og operativ beredskap.

Kontrollhub

Katalog- og brukerklargjøring

Webex Callingplattform

Støttede anropsendepunkter

PSTN-tilkoblingsalternativer

Webex Callingringeplan og nummerstyring

Sikkerhets- og samsvarsfunksjoner.

Hvis du vil ha mer informasjon, kan du se Cisco Preferred Architecture forWebex Calling.

Denne veiledningen vil fremheve verktøy og prosesser som skal brukes gjennom hele overgangslivssyklusen. Imidlertid kan en overgang fra lokale samtaler,Unified CM, til en ny plattform for skyanrop,Webex Calling, være en betydelig innsats med potensielle forretningsmessige, tekniske og komplekse utfordringer. For å hjelpe deg med å overvinne disse utfordringene har Cisco noen forskjellige alternativer tilgjengelig for å hjelpe deg med reisen din. Det er viktig å gå gjennom informasjonen i Enterprise Cloud Calling — Overføring av anrop og forstå hvert alternativ og hvordan hvert enkelt alternativ muligens kan hjelpe deg med din egen migrering.

Webex-migreringsverktøy: selvbetjente, gratis verktøy innebygd i Control Hub for å effektivisere overgangen til Webex Calling

Sertifiserte overføringsleverandører: Cisco-validerte programvare- og verktøyleverandører som har utviklet overføringsløsninger for å hjelpe Webex-partnere og kunder med komplekse og store migreringer. Disse løsningene kan bidra til å forenkle, administrere og akselerere overgangen til Webex Calling

Webex Setup Assist: en Cisco-ledet overføringstjeneste som veileder kunder og partnere gjennom Webex Calling distribusjonen og konfigurasjonen, som er nødvendig for å overføre Unified CM brukere og tjenester til. Webex Calling

Oversikt

Med veksten av skyleverte samarbeidstjenester, ønsker flere kunder å flytte sine eksisterende samarbeidsarbeidsbelastninger til skyen gitt løf tene om reduserte totale eierkostnader, forenklet administrasjon, kontinuerlig funksjonsleveranse, økt skala og overlegen pålitelighet iboende i skybaserte tjenester. Når kundene ønsker å gjøre overgangen fra lokale til skybaserte samarbeidstjenester, er det viktig for dem å forstå hva overgangen innebærer, og trinnene som kreves for å gjøre overgangen.

Formålet med dette dokumentet er å gi distribusjonsveiledning for kunder som spesifikt ønsker å gå fra lokalt Unified CM til Webex Calling i skyen. Denne distribusjonsveiledningen forutsetter at leseren har en grunnleggende forståelse av anropsovergangen mellom Unified CM ogWebex Calling, inkludert hva som endres når du foretar denne overgangen, og hva forskjellene er når du flytter anropsarbeidsmengden fra lokal til skyen. Før du fortsetter, sørg for at du har gjennomgått og er kjent med informasjonen som er tilgjengelig i overgangskartet. Dette overgangskartdokumentet gir informasjon om endringene og forskjellene i denne overgangen.

Som vist i figur Lokal samarbeidsarkitektur: samtalekontroll og ekstern tilgang inkluderer en typisk lokal distribusjon forskjellige samarbeidsinfrastruktur komponenter på nettverket, en samtal ekontrollplattform, en kantplattform, maskinvare- og programvareendepunkter, og i noen tilfeller til og med konferanse- og planleggingsplattformer. I Cisco- arkitekturen vil dette omfatte Unified CM samtalekontroll, Expressway for ekstern tilgang og business-to-business (B2B) edge-tjenester, Cisco Meeting Server/ Cisco Meeting Management for lokale konferanser, Unity Connection for talemeldinger og brukervendt maskinvare (Cisco IP-telefoner, Cisco Desk and Room video systemer) og programvare () IP-baserte endepunkter. Cisco Jabber Disse komponentene kan variere noe i noen miljøer, men dette er utgangspunktet for overgangen beskrevet i resten av dette dokumentet.

Lokal samarbeidsarkitektur: samtalekontroll og ekstern tilgang

Arkitekturen vist i figur Lokal samarbeidsarkitektur: anropskontroll og ekstern tilgang er basert på Preferred Architecture (PA) for Cisco Collaboration Enterprise On-Premises Deployments. Hvis du vil ha mer informasjon om Enterprise On-premise, kan du se Ciscos foretrukne samarbeidsarkitekturer.

Før: Tabellen for lokale anropsinfrastrukturkomponenter viser nøkkelelementene Webex Calling i den lokale arkitekturen før overgangen til skyen.

Tabell 1. Før: Lokale anropsinfrastrukturkomponenter
Produkt Beskrivelse

Unified CM Lokal anropskontroll som gir enhetsregistrering og samtalerutingstjenester

Cisco Expressway-C/E Edge-infrastruktur som gir mobil- og Remote Access (MRA) og business-to-business (B2B) funksjonalitet som gjør det mulig for eksterne endepunkter å koble seg sikkert fra utenfor organisasjonen. Expressway distribueres parvis for å gi brannmur kryssing for eksterne endepunkter.

Cisco møteserver (CMS), Cisco møteadministrasjon (CMM) og Cisco TelePresence Management Suite (TMS) Lokal tale-, video- og nettkonferanseinfrastruktur som gir flerpunktmøter, møteadministrasjon og planleggingsfunksjoner. [Valgfritt]

Cisco Unity Connection Lokal talemeldingsplattform som gir talepost og enhetlige meldingsfunksjoner. [Valgfritt]

Cisco Desk, Cisco Room, Cisco Board, Cisco IP-telefoner og Cisco Jabber IP-baserte enheter som er registrert på Unified CM og gir mulighet for tale- og videosamtaler

Som illustrert i Figur Overgangsvedtak: lokal samtale til Webex Calling, kunder som har en lokal samtalekontroll med Unified CM skrivebords- og video-IP-endepunkter, kan velge mellom å overføre arkitekturen til en skyarkitektur. Webex Calling

Beslutningen må tas basert på kundens funksjonalitetskrav. Kunder som har følgende krav, bør vurdere nøye før de tar denne beslutningen, og kan til slutt bestemme seg for å beholde samtalekontrollen lokalt:

Telefonmodeller støttes ikke av Webex Calling

Komplekse eller mange integrasjoner med andre lokale systemer eller løsninger, spesielt der Webex Calling det er vanskelig å replikere disse integrasjonene med eller ingen tilsvarende alternative løsninger er tilgjengelige

Kompleks nummerplan, svært detaljerte tjenesteklasser eller begge deler

Begrenset, begrenset eller upålitelig Internett-tilgang

Strenge retningslinjer for personvern og eierskap

Overholdelseskrav for opptak og lagring av medier lokalt eller i land

Tredjepartsintegrasjoner uten levedyktig alternativ Webex Calling integrasjon

Kontaktsenterintegrasjoner der kontaktsenteret ikke flytter til skyen ennå.

Overgangsvedtak: lokal anrop til Webex Calling
Kunder som ønsker å begynne å utnytte skysamtaletjenester, bør vurdereWebex Calling. Denne skysamtaletjenesten lar kunden utnytte Webex globale arkitektur for skalering og tilkobling. Deltakere i bedriftsnettverket og eksterne deltakere utenfor bedriftsnettverket kan kommunisere ved hjelp av IP-baserte maskin vareendepunkter og/eller desktop- eller mobile myke klientapplikasjoner.

Dette dokumentet fokuserer på kunder med Unified CM distribusjoner for samtalekontroll som ønsker å forstå de generelle trinnene, hensynene og kravene for å aktivere Webex Calling distribusjon som vist i neste avsnitt.

Kjernekomponenter

Målarkitekturen for denne overføringen inkluderer flere nye komponenter. Dette inkluderer Webex Calling tjenesten for skybaserte anrop, Webex App, Cisco Directory Connector for identitetsintegrasjon og Local Gateway (LGW) for PSTN- tilgang, samt lokal til skybasert anropsintegrasjon. Cisco Calling Plans eller Cloud Connec ted PSTN (CCP) tilrettelagt av en Cloud Connect for Webex Calling partner er tilleggsalternativer for PSTN-tilgang.

Som vist i Figur A fter: Webex Calling Architecture, legges de nye komponentene (Webex Calling, Katalogkontakt, Lokal gateway og Overlevelsesgatewayen) til i den eksisterende lokale distribusjonen.

Etter: Webex Calling Arkitektur

Etter: Tabellen for skyanropsinfrastrukturkomponenter viser de nye elementene i arkitekturen etter overgang til Webex.

Tabell 2. Etter: Infrastrukturkomponenter for skyanrop
Produkt Beskrivelse

Webex Calling Skybasert anropstjeneste levert fra Webex-plattformen og gir endepunktregistrering og samtaleruting

Cisco katalogkontakt Windows-program som kjører på en Windows-domenemaskin som gir identitet ssynkronisering mellom bedriften lokalt Active Directory og identitetslageret til Webex-organisasjonen.
For kunder som flytter fra lokal Active Directory til Entra ID, bruker identitetsintegrasjonen med Webex i stedet for Cisco Directory Connector Entra ID-veiviserappen.

Lokal gateway En lokal gateway fungerer som en bro mellom kundens lokale enhetlige kommunikasjonsnettverk og Webex Calling skyen. Den kan distribueres lokalt eller hostes av en partner, og leverer PSTN- tilgang for skyregistrerte endepunkter, samt anropsintegrasjon mellom registrerte og sky Unified CM registrerte endepunkter. Cisco IOS-XE Integrated Services Router (ISR 1100- og 4000-serien), Cisco Catalyst 8200/8300-serien, Cisco Catalyst 8000V Edge- programvare og forskjellige sertifiserte tredjeparts Session Border Controllers (SBC) kan brukes som en LGW for en trinnvis migreringstilnærming.

Gateway for overlevelsesevne Survivability Gateway (SGW) er en lokal nettverks-IOS-XE-basert gateway som gir tilbakekallingstjenester til endepunkter på stedet Webex Calling under nettverksbrudd.

Cisco anropsplan, Cloud Connect for Webex Calling Cisco Calling Plan og Cloud Connect for Webex Calling er skybaserte alternativer for PSTN-tilgang for Webex Calling endepunkter. PSTN-tilgang tilrettelegges av en skybasert PSTN-leverandør og krever ikke lokalt utstyr.

Webex-appen Klientapplikasjon som kjører på stasjonært OS (Windows, Mac) eller mobilt OS (Android, iOS) og registrert direkte på Webex Calling plattformen for anropsfunksjonalitet.

PPDIO prosessoversikt

PPDIO- prosessen står for forberede, planlegge, designe, implementere og optimalisere. Det er en strukturert Cisco-metodikk som veileder prosjekter fra første vurdering gjennom kontinuerlig forbedring, og sikrer effektive og vellykkede distribusjoner eller migreringer.

PPDIO prosess

Generell beskrivelse av PPDIO

Forbered deg: Vurder det nåværende miljøet, samle krav og justere interessenter for å etablere et solid fundament.

Plan: Ut vikle detaljerte prosjektplaner inkludert tidslinjer, ressurser og risikoreduserende strategier.

Design: Arkitekt målløsningen skreddersydd til forretningsmessige og tekniske behov.

Implementere: Utfør distribusjonen eller migreringen i henhold til designet, validere funksjonalitet og ytelse.

Optimaliser: Forbedre løsningen kontinuerlig etter implementering ved å overvåke ytelse, foredle konfigurasjoner og utnytte automatiserings- og integrasjonsverktøy.

Bruke PPDIO for Unified CM til Webex Calling migreringsprosjekter

Ved overgang fra Unified CM til Webex Calling gir PPDIO-prosessen et klart veikart for å sikre en jevn og effektiv overgang:

Forberede

Vurdere eksisterende Unified CM miljø og migrasjonsberedskap

Samle inn detaljerte data om brukere, enheter, nettverk og avhengigheter

Samle inn stedsinformasjon inkludert beredskapsadresse, antall brukere, internet tilgang, PSTN-tilgang

Identifiser risikoer og definer prosjektomfang for å tilpasse alle interessenter.

Planlegg

Opprett en omfattende overføringsplan med batchplaner, ressurstildelinger og tidslinjer

Definere oppgaver som oppgraderinger av fastvare for enheter, lisensklarering og brukerinnføring

Koordiner migreringsvinduer med Cisco og partnere for å minimere forstyrrelser.

Utforming

Tilordne gjeldende Unified CM konfigurasjoner, nummerplaner og brukerprofiler til Webex Calling ekvivalenter

Utforme Webex Calling miljøet, inkludert PSTN-strategi (midlertidig og endelig), lokasjoner, brukerroller og integrasjonspunkter som Local Gateway (CUBE) og katalogsynkronisering

Planlegg for sameksistensscenarier der Unified CM og Webex Calling opererer samtidig under migrering.

Implementere

Bruk Control Hub-migreringsverktøy sammen med tredjepartsverktøy for å utføre endringer i enhetens fastvaremodus, funksjonskonfigurasjon og brukermigrering

Bruk masseoperasjoner og klargjøring ved hjelp av Webex API-er for å effektivisere store overføringer og konfigurasjoner

Utfør lisensklargjøring, enhetsregistrering og konfigurasjonsoppdateringer

Valider overføringssuksess gjennom testing og operativ verifisering.

Optimaliser

Kontinuer Webex Calling lig overvåke ytelse og brukeropplevelse

Avgrens konfigurasjoner og arbeidsflyter basert på driftsdata og tilbakemeldinger

Utnytt automatiserings- og integrasjonsfunksjoner for å forbedre effektiviteten og skalerbarheten

Avslutt eldre Unified CM komponenter etter behov og gi kontinuerlig støtte for dag-2-operasjoner.

Denne forbedrede PPDIO-tilnærmingen sikrer en kontrollert, gjennomsiktig og effektiv migrering fra Unified CM til, ved å utnytte Ciscos verktøyWebex Calling, API-er og partnerøkosystem for å opprettholde forretningskontinuitet og forbedre samarbeidsmulighetene.

PPDIO tilbakemeldingssløyfer

Oversikten på høyt nivå som er avbildet i figur iterasjoner mens du utfører PPDIO illustrerer en enkelt tilbakemeldingssløyfe fra optimalis eringsfasen tilbake til forberedel sesfasen. Dette betyr at det etter den første implementeringen er en kontinuerlig mulighet for kontinuerlig forbedring. Hver optimaliseringssyklus kan identifisere nye krav eller forbedringsområder, som kan adresseres gjennom påfølgende prosjekter eller initiativer. Disse individuelle prosjektene følger i sin tur hver den etablerte PPDIO (Prepare, Plan, Design, Implement, Optimize) livssyklusen. Denne iterative tilnærmingen sikrer at systemet forblir på linje med utviklende forretningsmål og teknologiske fremskritt, og fremmer en kultur med kontinuerlig raffinement og tilpasningsevne.

Iterasjoner mens du kjører PPDIO

Under gjennomføringen av PPDIO-prosessen er det vanlig at funn i de senere fasene nødvendiggjør revurdering og potensielt revisjon av beslutninger tatt i tidligere stadier. For eksempel kan problemer som oppstår i implementeringsfasen, for eksempel identifisering av tvetydigheter i design eller manglende detaljer, avsløre at visse aspekter ikke ble fullstendig adressert i designfasen. I slike tilfeller blir det nødvendig å gjenta tilbake til den aktuelle tidligere fasen for å løse disse problemene før du fortsetter. Denne iterative tilbakemeld ingsmekanismen, som illustrert i figur Unified CMassistert PPDIO-prosess, sikrer at løsningen blir grundig validert og raffinert, og til slutt bidrar til en mer robust og effektiv distribusjon.

Unified CMassistert PPDIO prosess

Når du foretar en overgang fra Unified CM tilWebex Calling, kan hver fase av PPDIO-prosessen ha betydelig nytte av informasjon samlet inn fra det eksisterende Unified CM miljøet. For eksempel kan omfattende varebeholdninger av brukere, telefonnumre, anrops funksjoner og oppringeplankomponenter hentes ut fra gjeldende Unified CM konfigurasjon. Disse dataene supplerer informasjon gitt direkte av interessenter og hjelper til med å effektivisere planleggings- og designaktiviteter. Å utnytte passende verktøy for å automatisere dat autvinning og analyse forbedrer ikke bare nøyaktigheten, men akselererer også den generelle prosessen. Ved å utnytte innsikt fra den eksisterende distribusjonen, Webex Calling kan overgangen til utføres mer effektivt enn en tradisjonell greenfield-implementering, mens den fortsatt følger den struktur erte PPDIO-metodikken. Denne prosessen er illustrert i figur Unified CMassistert PPDIO-prosess.

Migrasjonstilnærming

Når du planlegger overgangen fra lokal Unified CM til lokalWebex Calling, må du bestemme hvordan du vil tilnærme deg denne reisen. Først må du bestemme om migr eringen vil være en flash-cut (alt på en gang) eller en trinnvis tilnærming (migrere grupper av brukere/enheter over en lengre periode).

Ved å gjøre en flash-cut- migrering flyttes alle brukerne og enhetene dine raskest. Med denne metoden flytter du alle brukere og enheter fra lokalt Unified CM til Webex Calling samtidig. I hovedsak er det ett enkelt migrasjonsvindu for alle brukere og enheter. Etter at denne overføringen er fullført, vil alle brukerne og enhetene dine være på Webex Calling plattformen, og all Unified CM infrastrukturen din kan tas ut av drift. Mange organisasjoner kan imidlertid ikke bruke denne tilnærmingen på grunn av omfanget og størrelsen på anropsdistribusjonen.

Den andre tilnærmingen er en trinn vis migrasjon. De fleste organisasjoner vil bruke denne tilnærmingen da den gir bedre kontroll, styring og skalering med migreringen. Den er også bedre egnet for større UC-distribusjoner og/eller distribusjoner på tvers av flere regioner. Derfor fokuserer dette dokumentet på den trinn vise tilnærmingen med to trinn i overgangen.

Som vist i figuren nedenfor Faset anropsovergang: Hybrid og sky, resulterer den første overgangsfasen (fase 1) i en sameksistensdistribusjon med doble anropsmiljøer. I denne fasen blir noen brukere, enheter og myke klienter overført til Webex Calling mens andre fremdeles er på den lokale anropskontrollenUnified CM. Den siste overgangsfasen (fase 2) resulterer i et rent sky anropsmiljø der alle brukere, enheter og myke klienter har blitt fullstendig overført til Webex Calling plattformen.

Hvor lang tid det tar en organisasjon å fullstendig gå over til skyanrop, vil variere basert på gjeldende distribusjon. I noen tilfeller kan en organisasjon foreta den første overgangen og forbli i sameksistens dual call control fase (fase 1) i en lengre periode (måneder eller til og med år), mens i andre tilfeller kan en organisasjon fullstendig gå over til Webex Calling (fase 2) i en veldig kort periode (uker eller måneder). Dette dokumentet er ment å dekke begge faser (fase 1 - sameksistens og fase 2 - fullstendig overgått).

Trinnvis anropsovergang: hybrid og sky

Det er mulig at noen organisasjoner kan opprettholde en sameksistens med dobbel samtalekontroll distribusjon på ubestemt tid uten planer om noen gang å fullstendig overgå til skyanrop.

Den andre vurderingen er hvordan du vil overføre brukere, enheter og myke klienter fra den lokale samtal ekontrollen til skysamtalekontrollen. Den anbefalte tilnærmingen er en 3-fas et overgang. Figuren Anbefalt 3-faseovergang nedenfor bryter ned denne tilnærmingen i 3 faser.

Anbefalt 3-faseovergang

Før migrering: Denne fasen fokuserer på å gjøre både Webex og Unified CM miljøene klare for migreringen. Dette handler ikke om å ringe spesifikk planlegging eller konfigurasjoner, og fokuserer på å fullføre aktiviteter som kan gjøres nå og før et Webex Calling migreringsprosjekt starter. Målet er å bygge grunnlaget for at de to miljøene skal forberede seg på migrasjonen.

Migrasjonsforberedelse: Denne fasen begynner innsatsen for å forberede migreringen til Webex Calling. Her må forretningsmessige og tekniske krav gjennomgås og oppdateres. Ikke bare gjør et løft og skift av det som for øyeblikket er implementert med, Unified CM og omdefiner i stedet de forretningsmessige og tekniske kravene som bedriften din trenger i dag og i fremtiden ved å utnytte kraften til. Webex Calling I tillegg er dette fasen der du vil fullføre design, konfigurasjons planlegging og migreringsplanlegging/tidsplan.

Migrering (utrulling og avvikling): Denne fasen er der den faktiske migreringen av brukere, enheter, telefonnumre og myke klienter skjer. Som diskutert ovenfor kan denne fasen fullføres for alle på en gang (flash-cut) eller over flere endringsvinduer (fas et kutt). Adopsjonsplaner for sluttbrukere, opplæring og kommunikasjon er avgjørende, slik at brukerne dine er klar over endringene, hvordan de bruker den nye samtaleplattformen, og vet når en dringen vil skje. Det siste trinnet er å deaktivere all lokal UC-infrastruktur som ikke lenger brukes.

Fasen før migrering har aktiviteter (påkrevd, anbefalt og valgfritt) som du kan begynne å jobbe med umiddelbart. Det anbefales å fullføre disse før heller enn senere og helst før prosjektet begynner. Noen av aktivitetene kan ta lengre tid å fullføre, og å starte dem tidligere vil derfor bidra til å effektivisere det faktiske overføringsprosjektet ditt.

Figuren Pre-Migration Activi ties nedenfor fremhever fem spesifikke kategorier av aktiviteter som er relatert til en Webex Calling migrering.

Aktiviteter før migrasjon

Forberede

Forretnings- og tekniske krav

Hvorfor det er viktig å samle krav:

Forretningskrav

Tekniske krav

Nettverksberedskap og krav

Konfigurere skytilkoblet UC

Vurdering av dagens miljø

Lisensiering

Steder/steder

Inventar eksisterende enheter/klienter

Bekreft enhetens kvalifisering

Brukere

PSTN-tilkobling

Funksjoner og funksjonsbruk

Cisco-integrasjoner: Unity Connection UCCX UCCE

Samtaleopptak

Tredjepartsintegrasjoner

Forretnings- og tekniske krav

Når du planlegger en migrering fra til, er det avgjørende å grundig samle både tekniske og forretningsmessige krav i planleggingsfasen. Dette trinnet sikrer at migrering stemmer overens med organisasjonens operasjonelle mål og tekniske evner, og minimerer risiko og forstyrrelser.

Hvorfor det er viktig å samle krav:

Justerer forretningsmessige mål: For ståelse av forretningsbehov hjelper deg med å skreddersy migreringen for å støtte viktige arbeidsflyter, brukeropplevelse og vekstplaner.

Sikrer teknisk kompatibilitet: Å identifisere tekniske krav tidlig forhindrer integrasjonsproblemer med eksisterende infrastruktur, nettverk og endepunkter.

Tilrettelegger for ressursplanlegging: Tydelige krav bidrar til å estimere tidslinjer, kostnader og nødvendige ressurser nøyaktig.

Reduserer risiko: Tidlig oppdagelse av potensielle utfordringer gir mulighet for proaktive løsninger, reduserer nedetid og serviceavbrudd.

Forretningskrav

Typiske forretningskrav inkluderer:

Antall brukere og steder som skal overføres

Ønskede funksjoner og tjenester (eksempel samtaleruting, telefonsvarer, konferanser, automatiske svarmenn, samtal ekøer)

Retningslinjer for samsvar og sikkerhet

Budsjettbegrensninger og kostnadsforventninger

Brukeropplæring og støttebehov

Overføringstidslinje og forretningskontinuitetshensyn.

Å samle ønskede funksjoner og tjenester er et kritisk skritt for å sikre at det nye systemet oppfyller forretningsbehov. Når du samler disse kravene, er det viktig å ikke bare vurdere hva som for øyeblikket er konfigurert i, men prøve å samle de faktiske kravene fra forretningsenhetene som skal bruke systemet. Ellers er det fare for at planen er basert på langsiktige forutsetninger. Sørg for å evaluere flere eller forbedrede funksjoner som er tilgjengelige i som kanskje ikke finnes i, for eksempel skybaserte anrop, avanserte samtalekøer, , og. Dette hjelper deg med å utnytte de fulle fordelene med skyplattformen.

Når du evaluerer gjeldende konfigurasjon i, er det viktig å erkjenne at ikke alle eksisterende innstillinger kan forbli nødvendige på grunn av utvikl ende krav gjennom systemets livssyklus. Fokuset bør være på å identifisere og beholde bare de konfigurasjonene som samsvarer med nåværende og fremtidige behov for distribusjonen.

Fokuser mer på det du trenger enn det du har.

Samsvars- og sikkerhetspolicyer er viktige hensyn under overføringen fra til Webex Calling for å sikre at det nye skybaserte kommunikasjonssystemet overholder juridiske, forskrift smessige og organisatoriske standarder.

Overholdelse av forskrifter: Organisasjoner må verifisere at de oppfyller bransjespesifikke forskrifter som GDPR, HIPAA eller SOX, og adresserer krav til personvern, oppbevaring og håndtering av data, samt landsspesifikke mandater knyttet til dataopphold, bompengeomgåelse og medielokalitet.

Datasikkerhet: Sikre at tale- og signaldata krypteres både i transitt og i hvile for å beskytte mot avlytting eller uautorisert tilgang.

Tilgangskontroller: Definere og håndheve brukerautentisering, autorisasjon og rollebasert tilgang for å forhindre uautorisert bruk av kommunikasjonsressurser.

Tilsyn og overvåking: Im plementering av logging og overvåkingsfunksjoner for å spore tilgang og bruk for samsvarsrevisjoner og undersøkelser av sikkerhetshendelser.

Retningslinjejustering: Tilpass overføringen med eksisterende sikkerhetspolicyer for bedriften, inkludert endepunktssikkerhet, nettverkssegmentering og hendelsesresponsplaner.

Leverandørsikkerhetsforsikring: Evaluering av Ciscos sikkerhetssertifiseringer og samsvarserklæringer for å sikre pålitelighet.

Å håndtere disse retningslinjene for samsvar og sikkerhet i planleggingsfasen bidrar til å redusere risiko, unngå rettslige straffer og opprettholde integriteten og konfidensialiteten til kommunikasjonen gjennom og etter overføringen.

Brukeropplæring og støttebehov er viktige komponenter under migreringen fra til for å sikre en jevn overgang og brukeradopsjon. Viktige hensyn inkluderer:

Opplæringsprogrammer: Utvikle skreddersydde treningsøkter for ulike brukergrupper (sluttbrukere, administratorer, helpdesk-ansatte) for å gjøre dem kjent med funksjoner, brukergrensesnitt og nye arbeidsflyter.

Dokumentasjon: Gi klare, tilgjengelige brukerveiledninger, vanlige spørsmål og hurtigreferans emateriell, inkludert ressurser for nyheter og forskjellige ressurser og trinnvise veiledninger før og etter (i video- eller hurtigveiledningsformat), for å støtte brukerne når de tilpasser seg den oppdaterte opplevelsen etter migrering.

Endringsadministrasjon: Kommuniser endringer proaktivt for å håndtere brukernes forventninger og redusere motstand.

Støttestruktur: Etablere et dedikert støtteteam eller opptrappingsbane for å løse brukerproblemer raskt under og etter overføringen.

Pågående utdanning: Planlegg for kontinuerlige opplæringsoppdateringer når nye funksjoner eller oppdateringer sli ppes i.

Tilbakemeldingsmekanismer: Implementere kanaler for brukere for å rapportere problemer og gi tilbakemelding for å forbedre opplærings- og støtteprosesser.

Å adressere disse trenings- og støttebehovene i planleggingsfasen bidrar til å minimere forstyrrelser, forbedrer brukernes tillit, og maksimerer fordelene ved å migrere til.

Tekniske krav

Flere viktige tekniske krav må samles inn og dokumenteres for en vellykket migrering fra til, inkludert detaljer for:

Nettverksberedskap og båndbreddekapasitet

En omfattende nettverksvurdering er avgjørende for å sikre at din eksisterende infrastruktur kan støtte det nye Webex Calling miljøet. Dette inkluderer:

Båndbreddeanalyse: Evaluering av nåværende og projisert båndbreddebruk for å håndtere tale-, video- og datatrafikk uten overbelastning.

Kvalitet på tjenesten (QoS): Implementering av QoS-policyer for å prioritere taletrafikk og minimere ventetid, jitter og pakketap.

WAN og Internett-tilkobling: Verifisere at WAN-koblinger og internettforbindelser oppfyller kravene for skybaserte anrop, inkludert redundans- og failover-funksjoner.

Brannmur- og NAT-konfigurasjon: Sikre at brannmur- og NAT-innstillinger tillater nødvendig signalering og medietrafikk for.

Integrasjon med eksisterende system

Sømløs integrasjon med eksisterende forretningssystemer er avgjørende for brukeropplevelse og kontinuitet i arbeidsflyten:

Katalogtjenester: Vurdering av integrasjon med en bedriftskatalog for automatisk klargjøring og godkjenning av brukere.

CRM og forretningsapplikasjoner: Identifis ere integrasjonspunkter med kunde forholdsstyringssystemer og andre forretningskritiske applikasjoner.

Legacy PBX-samarbeiding: Planlegging for sameksistens eller trinnvise migrerings strategier hvis noen eldre telefonisystem vil forbli under overgangen.

Endepunktkompatibilitet og klargjøring

Alle endepunkter, inkludert skrivebordstelefoner, softphones og mobile enheter, bør evalueres for kompatibilitet:

Enhetsstøtte: Bekreft at eksisterende IP-telefoner og enheter støttes av eller identifiserer nødvendige erstatninger.

Klargjøringsprosesser: Etablere automatiserte eller strømlinjeformede klargjøringsm etoder for effektiv onboarding av endepunkter.

Fastvare- og programvareoppdateringer: Planlegging av nødvendige oppdateringer for å sikre interoperabilitet og sikkerhet.

Sikkerhetskonfigurasjoner og krypteringsstandarder

Sikkerhet er avgjørende i skykommunikasjon:

Kryptering: Håndheve ende-til-ende-kryptering for signalering og mediestrømmer, i tråd med Ciscos beste sikkerhetspraksis.

Autentisering og tilgangskontroll: Im plementering av sikre autenti seringsmekanismer (for eksempel SSO, multifaktorautentisering) og granulære brukertilgang skontroller.

Overholdelse: Sikre at løsningen oppfyller relevante regulatoriske standarder og brans jestandarder (f.eks. GDPR, HIPAA).

Sikkerhetsovervåking: Integrering med SIEM-verktøy og konfigurering av varsling for potensielle sikkerhetshendelser.

Tabell 1. Eksempelvurdering
Krav Viktige hensyn

Nettverksberedskap og båndbredde Båndbredde, QoS, WAN/Internett, brannmur/NAT

Integrasjon med eksisterende systemer Katalog, CRM, PBX, E-post/kalender

Endepunktkompatibilitet og klargjøring Enhetsstøtte, klargjøring, fastvareoppdateringer

Sikkerhetskonfigurasjoner og kryptering Kryptering, autentisering, samsvar, sikkerhetsovervåking

Brukeropplæring og endringsledelse Opplæringsprogrammer, dokumentasjon, endringskommunikasjon

Nummerportabilitet og nummerplan Nummermigrering/-portering, nummerplanoversettelse

Tredjepartsintegrasjoner Personsøking, kontaktsenter, faks, analoge enheter

Nettverksberedskap og krav

Nettverksberedskap er avgjørende for en vellykket migrering til en hvilken som helst skybasert anropsløsning som. Dårlig nettverksplanlegging kan føre til forringet samtalekvalitet, tapte samtaler og ulykkelige brukere. Kunder må gjennomføre en nettverksvurdering før de migrerer til. Det anbefales å bekrefte tilgjengeligheten av nettverksbåndbredde for forventet anrops volum, sikre at kravene til tjenestekvalitet (QoS) er oppfylt, og forstå de forskjellige portene som må åpnes i kantbrannmuren (e).

Pålitelig nettverkstilkobling med tilstrekkelig servicekvalitet (båndbredde, pakketap, RTT) er et grunnleggende krav for å sikre best mulig brukeropplevelse fra ende til ende for alle tale- og videokompatible endepunkter, klienter og applikasjoner som bruker.

Kunder og partnere har tilgang til tilkoblingsmuligheter utover OTT-Internett (Over-the-Top) som kan optimalisere tilkoblingen til å inkludere Webex Edge Connect. Hvis du vil ha mer informasjon om Webex Edge Connect- designdetaljer, kan du se Cisco Preferred Architecture for Webex Edge Connect forWebex Meetings, Calling Multi-Tenant og Dedikert fore komst.

Kunder kan bruke cScan for nettverksvurdering som gir informasjon om kundens nettverkskvalitet, hvor mange samtaler som kan etableres, ventetid og så videre. Hvis du vil ha mer informasjon om cScan-verktøyet, kan du se Bruke cScan til å teste Webex Calling nettverkskvaliteten.

For å sikre at nettverket er klart for overføring til, bør du vurdere følgende sjekkliste:

Båndbreddeplanlegging

Beregn samtidige anrop per nettsted for å sikre at du har nok oppstrøms og nedstrøms båndbredde og inkludere takhøyde for annen forretningskritisk trafikk og fremtidig vekst.

Bånd Webex Callingbreddeberegningstab ellen for samtaletype viser samtaletypene som er tilgjengelige med en distribusjon sammen med kodeken og maksimal båndbredde som kreves for hver anropstype. Som vist i tabellen for bånd Webex Calling breddeberegninger av anropstypen, kan den nødvendige båndbredde for lydanrop for hver anrop stype beregnes ved å bruke følgende generelle formel:

Antall forventede samtidige anrop * Båndbredde per samtale basert på kodek = Nødvendig nettverksgjennomstrømning.
Tabell 2. Webex Callingbåndbredde beregninger av anropstype
Samtaletyper Codec - båndbredde Båndbreddeberegninger
/Skrivebordstelefon -> OPUS - 70 kbps Antall samtidige anrop* 70 kbps = Nødvendig nettverksgjennomstrøm ning
/Skrivebordstelefon -> Skrivebordstelefon OPUS — 70 kbps Antall samtidige anrop* 70 kbps = Nødvendig nettverksgjennomstrøm ning
/Skrivebordstelefon -> PSTN via LGW G.711 — 80 kbps Antall samtidige anrop* 80 kbps = Nødvendig nettverksgjennomstrøm ning
/Skrivebordstelefon -> PSTN via Cloud PSTN (f.eks. Cisco-anropsplan) G.711 — 80 kbps Antall samtidige anrop* 80 kbps = Nødvendig nettverksgjennomstrøm ning
/Skrivebordstelefon -> Enterprise via LGW G.722 — 80 kbps Antall samtidige anrop* 80 kbps = Nødvendig nettverksgjennomstrøm ning
/Skrivebordstelefon -> telefonsvarer OPUS — 70 kbps Antall samtidige anrop* 70 kbps = Nødvendig nettverksgjennomstrøm ning

Ved å summere den samtidige nødvendige nettverksgjennomstrømning per anrop stype, kan det totale potensielle båndbreddebehovet for et bestemt sted bestemmes.

Alle anropsben er alltid forankret på tilgangs-SBC-ene. For å bestemme den nødvendige internettbåndbredde for et gitt sted, må ikke bare samtalene mellom lokasjonene vurderes, men også intra-lokasjonsanrop og samtaler til og fra en lokal gateway på det stedet. For eksempel vil en samtale mellom to MPP-telefoner trenge opptil 2 x 70 kbps full dupleks på stedets internetttilgang.

Tabellen med eksempler på Webex Calling båndbreddeberegning viser et eksempel på en fullstendig båndbred deberegningsøvelse, forutsatt at alle enhetene er på samme sted.
Tabell 3. Webex Callingbåndbreddeberegningsek sempler
Samtaletyper Antall samtidige samtaler Total båndbredde
Webex-app/skrivebordstelefon → Webex-app 15 2 * 15 * 70 kbps = 2100 kbps
Webex-app/skrivebordstelefon → Skrivebordstelefon 15 2 * 15 * 70 kbps = 2100 kbps
Webex-app/skrivebordstelefon → PSTN via LGW 50 2 * 50 * 80 kbps = 8000 kbps
Webex-app/skrivebordstelefon → PSTN via Cloud Connect for Webex Calling 0 0* 80 kbps
Webex-app/skrivebordstelefon → Enterprise via LGW 15 2 * 15 * 80 kbps = 2400 kbps
Webex-app/skrivebordstelefon → Talepost Webex Calling 5 5 * 70 kbps = 350 kbps
Totalt antall anrop/båndbredde 100 samtaler 14 950 kbps/14,95 Mbps

Alle båndbreddeverdier i tabellene ovenfor refererer til IP-båndbredde. Koblingsbåndbredde er høyere avhengig av WAN-innkapslinger.

Båndbredden i tabellene ovenfor er for lydan rop. For båndbredde for videosamtaler støtter Webex-appen og MPP 8845/65-telefonene H.264-video med maksimal oppløsning på 720p med en maksimal båndbredde på 1500 kbps per samtale . Mengden båndbredde som forbrukes på et hvilket som helst punkt under samtalen vil imidlertid variere basert på variabel bithastighet iboende i videokommunikasjon.

Kvalitet på tjenesten (QoS)

Implementere QoS-policyer i det lokale miljøet for å prioritere sanntidstrafikk, og sikre at QoS opprettholdes på tvers av svitsjer, rutere og brannmurer.

Mål for ventetid, jitter og pakketap

Følgende terskler anbefales for optimal talek valitet når samtaler går over-the-top (OTT) og over internett:

Latens - mindre enn 100 ms enveis

Jitter - mindre enn 10 ms

Pakketap - 0,5% eller mindre.

Brannmur og NAT

Kontroller at brannmuren er konfigurert til å tillate trafikk som oppført i artikkelen som er tilgjengelig under Portreferanseinformasjon for Webex Calling. Tillat i tillegg tilgang til domener og IP-områder som er oppført i samme guide, og unngå SIP ALG da det forstyrrer SIP-signalering. Medietra fikk gjennom proxyer bør unngås.

DNS og NTP

Sørg for riktig DNS-oppløsning av domener og pålitelige NTP-servere for å synkronisere enhetsklokker for TLS-sertifikatbekreftelse og logging.

Failover-planlegging

Vurder eksisterende leverandørdatatilkoblinger (MPLS, SD-WAN og så videre) og planlegg generelt for direkte internettilgang på hvert sted i distribusjonen. Planlegg redundante internett koblinger der høy tilgjengelighet er nødvendig. Fordi du vil konsumere skybaserte tjenester, er pålitelig internett forbindelse med tilstrekkelig båndbredde et grunn krav. Du bør vurdere å gjøre denne overgangen på nytt hvis organisasjonens lokasjoners internettforbindelse (er) generelt ikke er pålitelig med lav ventetid og tilstrekkelig gjennomstrømning opp og nedstrøms.

Nettstedets overlevelsesevne

Nettstedsoverlevelsesevne sikrer at virksomheten din alltid er tilgjengelig, selv om nettverkstilkoblingen går i stykker. Site Survivalability bruker en gateway i det lokale nettverket for å tilby en reserveanropstjeneste til endepunkter på stedet for situasjoner der nettverkstilkoblingen går i stykker. Vurder nettstedets overlevelsesevne med en lokal Survivalability Gateway (SGW) hvis forretningskrav krever kontinuerlig samtale i tilfelle nettverksbrudd. For mer informasjon om kontroll av nettstedets overlevelsesevne, se Nett stedets overlevelsesevne for. Webex Calling

Konfigurere skytilkoblet UC

Cloud Connected UC (CCUC) er en skybasert administrasjons- og analyseløsning designet for å gi sentralisert synlighet, administrasjon og innsikt for distribusjoner både lokalt (for eksempel) og sky (Unified CM). Det fungerer som en bro mellom tradisjonelle lokale miljøer og Ciscos skytjenester, og støtter organisasjoner gjennom hele migrerings reisen fra til.

Under overgangen til, CCUC spiller en viktig rolle i å effektivisere migreringsprosessen ved å legge til rette for inn samling av omfattende data fra den eksisterende Unified Communications-distribusjonen. CCUC bistår med viktige overgangsoppgaver som migrering av enheter, funksjoner og bruker kontakter, samt automatisering av firmwareoppdateringer for støttede IP-telefoner. Ved å gi sentralisert synlighet og administrasjon bidrar CCUC til å sikre en jevnere og mer effektiv migreringsopplevelse.

Cisco anbefaler på det sterkeste at CCUC distribueres og distribueres tidlig i overgangsprosjektet, ideelt før eller under forberedelsesfasen. Dette vil muliggjøre innsikten og mulighetene som trengs for å grundig vurdere, lagre og planlegge for påfølgende migrering saktiviteter og for å starte reisen til og fremtidige hybridfunksjoner.

Vurdering av dagens miljø

En viktig aktivitet i planleggingen av overføringen er å vurdere gjeldende lokale miljø og distribusjon. Dette gir innsikt i hvilke potensielle endringer som kan være nødvendige for å lykkes med overgangen til. Det lar deg også vurdere nøkkelelementene i plattformen i forhold til den eksisterende lokale distribusjonen. Du kan bruke denne informasjonen til å identifisere hvilke spesifikke oppgaver som kreves for overgangen, og hvilke endringer du vil gjøre for å oppfylle forretningsmessige og tekniske krav og brukstilfeller.

Følgende aspekter er viktige å gjennomgå som en del av denne innsatsen.

Lisensiering

Å forstå gjeldende lisensieringsstruktur for den eksisterende distribusjonen er nøkkelen når du forbereder migrering til. Utfør en lisensvurdering av følgende områder av din eksisterende lokale Cisco- løsning.

Plattform

Evnen til å fullt ut formulere hva som for øyeblikket er lisensiert på kjerneplattformen din, vil være avgjørende når du jobber med kontoteamet eller partneren din for å finne den beste veien til fleksibel lisensiering. er lisensiert ved hjelp av flex-lisensiering. Hvis du vil ha mer informasjon om fleksibel lisensiering, kan du se Cisco Collaboration Flex Plan.

Brukere og enheter

Identifiser hvilken lisenskategori eksisterende brukere og enheter krever. Dette vil bli brukt til å bestemme hvilken type lisens som kreves for brukerne og enhetene. tilbyr flere lisenstyper, inkludert Professional- og Standard-lisenser for brukere og Professional- og fellesområdelisenser for arbeidsområder. Hvis du vil ha mer informasjon om enhetslisensiering, kan du se databladet som er tilgjengelig på Enhetslisensiering.

Lokal gateway

Hvis Cisco Unified Border Element (CUBE) kreves for PSTN-tilgang for denne overgangen, må CUBE-lisensiering også vurderes. CUBE-lisensiering shensyn dekkes senere i dette dokumentet.

Steder/steder

Antall og typer områder (store sentrale, regionale, filialer osv.) innenfor den eksisterende distribusjonen bør vurderes når du planlegger denne overgangen. En full forståelse av de eksisterende distribusjonsstedene vil hjelpe deg med strategisk planlegging for en vellykket overgang, spesielt når det gjelder å bestemme hvilke nettsteder som skal migreres og i hvilken rekkefølge. Å forstå detaljerte krav til nummerplan (nummerering, oppringingsvaner, begrensningsklasser og så videre), nettstedsnettverkstilkobling og båndbredde (Internett, WAN, LAN) og PSTN-tilgang (lokal eller sentralisert, IP eller TDM) for hvert nettsted vil være avgjørende når du tar migreringsbeslutninger. Hvis du vil ha mer informasjon om vanlige distribusjonsmodeller og viktige hensyn, kan du se informasjonen om samarbeidsdistribusjonsmodeller som er tilgjengelig i Collaboration SRND.

En annen viktig distribusjonshensyn når du overgår til, er tilgjengelighet. har forskjellige funksjoner, abonnementer og enheter som er tilgjengelige avhengig av hvor distribusjonen din befinner seg. Hvis du vil ha mer informasjon om geografisk tilgjengelighet, kan du se Hvor er Webex tilgjengelig? .

Til slutt er det viktig å forstå hvilken innvirkning overgangen til vil ha på andre samarbeidstjenester. Basert på formålet med dette dokumentet er den generelle antagelsen at hvis eksisterende samarbeidstjenester utenfor anropsarbeids mengden skal opprettholdes, forventes overgang til fase 1 hybriddistribusjon nevnt ovenfor. Eksempler på samarbeidstjenester som kan kreve hybrid distribusjon inkluderer lokalt kontaktsenter som ennå ikke er migrert til Webex kontaktsenter, og tette integrasjoner i systemer som personsøkingssystemer og fakturering. Hvis du vil ha mer informasjon om overgangen til flere arbeidsbelastninger og tjenester for samarbeid, kan du se Samarbeidsoverganger.

Inventar eksisterende enheter/klienter

Før du starter overgangen, er det viktig å lagre eksisterende maskinvare- og programvareendepunkter. Å ha en fullstendig liste over enhetstyper/modeller, maskinvareversjoner, operativsystemtyper og mengder for myke klienter vil sikre at du kan planlegge tilstrekkelig for overgang av enhetene og redusere virkningen for de enhetene som ikke kan migreres til skyanrop. Inventaret skal brukes til å bestemme enhetene som skal overgå og enhetene som skal byttes ut før over gangen.

Skrivebordstelefoner

For skrivebordstelefoner med lyd og video støttes bare skrivebordstelefonene i 6800, 7800, 8800 og 9800-serien. Dette er et delsett av Cisco IP-telefoner som støttes med. Det er noen modeller og versjoner av 6800, 7800 og 8800-telefonene som ikke kan brukes med. Hvis du vil ha mer informasjon om hvilke modeller og maskinvareversjoner som støttes, kan du se Støttede enheter for Webex Calling.

Cisco 6800-seriens IP-telefoner kan ikke oppgraderes fra Enterprise firmware til Multiplatform (MPP) firmware, som kreves for. Derfor må alle 6800-telefoner som er registrert for kjørende bedriftsfastvare byttes ut med en 6800 MPP-modell eller med en annen støttet telefonmodell.

Cisco 7800- og 8800-seriens IP-telefoner må oppgraderes til Multiplatform Phone (MPP) firmware før overgang og registrering av dem til. Hvis du vil finne ut hvilke 7800- og 8800-modeller og maskinvareversjoner som støtter MPP-fast varen, kan du se Konvertere IP-telefoner i Cisco 7800- og 8800-serien mellom Enterprise - og MPP-fastvare.

8845, 8865 og 8865NR har nådd slutten av salget og anbefales ikke å migrere til.

Eldre versjoner av 8800-seriens telefoner (8811, 8841, 8851, 8851NR, 8861) anbefales ikke å bruke med. Webex Calling Telefoner med maskinvareversjoner VID 14 eller tidligere vil registrere seg med, men kan oppleve noen ytelsesproblemer på grunn av maskinvaren.

9800-seriens bordtelefoner kjører PhoneOS, som støtter både og registrering. Derfor kan disse telefonene overføres til uten fastvareoppgradering.

Alle andre IP-telefoner må byttes ut med telefoner i 6800, 7800, 8800 eller 9800-serien som støttes av. Webex Calling Hvis du vil ha mer informasjon om støttede IP- og skrivebordstelefoner med, kan du se artikkelen under Støttede enheter for Webex Calling.

Videoendepunkter

Endepunkter for personlige og romvideo, inkludert Cisco Board-serien, Room-serien og Desk- serien, kan SIP-registreres naturlig til. Alle disse endepunktene som må foreta lyd- og/eller PSTN-anrop krever en anropslisens:

Delte enheter i konferanserom, møteplasser osv. krever enten en Professional Workspace- eller Workspace-lisens.

En sluttbrukers personlige enhet krever en profesjonell eller standard lisens.

Bestem hvor mange videoendepunkter som er registrert til og brukes til å foreta lydanrop. Det er mulig at noen av videoendepunktene bare kan brukes til å delta i møter eller foreta SIP-videosamtaler. I begge tilfeller må sluttpunktene fortsatt migreres til før serverne tas ut av drift, men dette vil bidra til å avgjøre hvor mange av dem som trenger lisenser for å fortsette å ringe.

Når videoenheter flyttes fra registrering til, vil URI-en for disse endepunktene endres ettersom de nå er skyregistrert.

Telefonmodeller 8845, 8865 og 8875 er personlige video telefoner som støttes med.

Myke klienter

Det er den eneste myke klienten som støttes av, i motsetning til Unified CM som støtter både Webex-appen og Jabber, og er den nye standard myke klienten for sluttbrukere.

Avhengig av distribusjonsmodus (er) som er implementert for Jabber (modus for bare IM, bare telefon og/eller full UC-modus), kan det hende du også må vurdere overgangen av arbeidsbelastningene Meldinger og/eller Møter fra Jabber til. Den kan distribueres i telefon modus hvis den vil bli brukt som en klient som kun ringer, eller den kan distribueres som full Webex Suite hvis andre arbeidsbelastninger, f.eks. Webex Messagingog/ellerWebex Meetings, blir overført til appen med anrop.

Det forbedrer sluttbrukerens opplevelse ved å tilby AI-funksjoner som lyd/ videointelligens, samtaletranskripsjon og andre. Hvis du vil ha mer informasjon, kan du se https://www.webex.com/all-new-webex.

Før du flytter brukere til, må du overføre Jabber-klientene til. Du har to alternativer for å fullføre denne overgangen.

Før du overfører dem til

Når du overfører dem til.

For å lette den første overgangen til, anbefales det å bruke alternativ 1 og flytte brukere til med anrop først. Dette gir brukerne tid til å gjøre seg kjent med den nye applikasjonen mens de fremdeles bruker den eksisterende lokale anropsplattformen. Når du er klar til å flytte brukere til, vil du konfigurere dem til å registrere seg på skyanropsplattformen.

For mer informasjon om disse to alternativene, se Migrasjonsreise - ett eller to trinn? .

For en fullstendig liste over støttede enheter for, se Støttede enheter for Webex Calling.

Bekreft enhetens kvalifisering

Som nevnt tidligere støtter den et delsett av Cisco IP-telefoner og krever en annen fastvaretype for telefonene i 7800 og 8800-serien. Unified CMtelefoner kjører Enterprise-firmware mens telefoner kjører multiplatform Phone (MPP) firmware. Det anbefales å kontrollere hvilke registrerte telefoner som er kvalifisert for oppgradering til MPP-fastvaren i forberedelsesfasen. Dette gir deg tid til å erstatte ikke-kvalifiserte telefoner med en av de støttede telefonmodellene eller til å identifisere en alternativ plan, som å flytte en bruker bare til Webex-appen.

For å hjelpe deg med å bestemme kvalifiseringen til telefonene, har Control Hub et innebygd verktøy som heter Migrere telefonen til Webex Calling. Når du bruker dette verktøyet til å kontrollere enhetens kvalifisering, velger du alternativet Overføring Generer bare enhetslisens.

Control Hub-verktøyalternativ for å bekrefte at Unified CM telefoner er kvalifisert for Webex Calling

Dette alternativet lar deg laste opp en CSV-fil som inneholder telefonene, slik at du kan sjekke kvalifiseringen til hver telefon. Ved å velge dette migreringsalternativet, legger det ikke telefonene til siden du fremdeles er i forberedelsesfasen og ikke er klar til å gjøre dette ennå. Hvis du vil ha mer informasjon, kan du se Overføre telefonen til Webex Calling.

Det er mulig at noen av telefonene kan komme tilbake med en ukjent kvalif isering. Dette er vanligvis fordi det ikke er mulig å validere noe informasjon om telefonen i back-end-systemet. For alle telefoner som har U kjent status, har du to alternativer for å bekrefte om de er kvalifisert for å oppgradere til MPP-fastvaren.

Kontroller hver telefon manuelt og bekreft modell- og maskinvareversjonen (PID VID)

7800/8800 telefonetikett med modell- og maskinvareversjonsinformasjon

Bruk Cisco IP-telefonberedskapsverktøyet

Last ned verktøyet fra https://github.com/joemar2/mpp_readiness_check.

Dette verktøyet er ikke et offisielt Cisco-verktøy og støttes heller ikke TAC. Den har best mulig støtte, men er gratis å bruke.

Dette verktøyet må kjøres på en maskin som er lokal og kan få tilgang til serverne og IP-telefonene. Den har et alternativ for å aktivere netttilgang på IP-telefonene, som anbefales og trengs for å få de beste resultatene. Derfor bør den brukes i fritiden for å unngå forstyrrelser for sluttbrukerne. Utgangen fra verktøyet gir en rapport som viser hvilke av telefonene i 7800- og 8800-serien som er kvalifisert for å oppgradere til MPP-firmware. Fordi den får direkte tilgang til telefonen, kan den bekrefte de ukjente enhetene som ble rapportert fra Control Hub-verktøyet.

Rapport om Cisco IP-telefonberedskapsverktøy

Brukere

En av de viktigste forberedelsene for å sikre at du har en vellykket migrering, er riktig brukerklargjøring. Du må planlegge riktig for alle brukere selv om du gjør en trinnvis migrering. Brukere må være klargjort for ett av følgende:

Distribuere med anrop

Implementere med

Konfigurere tjenester for en bruker

For å gjøre brukere søkbare i katalogen (klikk for å ringe, Brukerkontaktinformasjon, telefonkatalogsøk).

Det anbefales at du klargjør alle brukere før eller ved starten av prosjektet. Dette inkluderer brukere som fremdeles bruker Unified CM for sin anropsplattform som er uavhengig av anropende enhet (IP-telefon, Jabber,). Når brukere blir migrert til (og/eller), oppdaterer du lisensene deres for å aktivere tjenestene de trenger. Ved å klargjøre alle bedriftsoppringende brukere før du starter overgangen, lar den en bruker som har gått over til eller søke i katalogen etter en bedriftsanropende bruker som fremdeles er på Jabber og/eller på. Dette sikrer at overførte brukere kan finne andre brukeres kontaktinformasjon og ringe til dem ved hjelp av katalogoppslaget.

Figur katalogsøket viser et eksempel på en bruker som søker etter en annen bruker. Søkeresultatene viser brukerens kontaktinformasjon og kan være for en bruker som fremdeles er på Jabber og eller for en bruker som har gått over til og/eller.

Webex App katalogsøk

Deretter bestemmer du hvilke av de eksisterende lokale anropsbrukerne som skal overføres til. Hvis alle eller et stort antall brukere skal overføres, anbefales det å flytte brukere i grupper for å sikre at prosjektteam, IT-ansatte og støttepersonell er i stand til å håndtere overgangen og eventuelle problemer som kan oppstå. Du bør også avsette litt tid til å gi innledende informasjon og opplæringsøkter for å forberede brukerne på denne overgangen. Gruppering av bruker overganger kan gjøres basert på en rekke kriterier, inkludert plasseringen eller nettstedet brukerne er tilordnet, brukeravdelinger eller til og med brukertyper (kunnskapsarbeidere, ledere, mobile arbeidere og så videre).

For eksempel, hvis brukere i distribusjonen er delt på tre hovedområder, New York (NYC), San Francisco (SFC) og Research Triangle Park (RTP), kan en brukerovergangsplan se ut som planen skissert i Brukerovergangsplan for områdetabell.
Tabell 4. Brukerovergangsplan etter nettsted
Bruker nettsted/plassering Informasjon og opplæringsøkter før overgangen Overgangsperiode Støtte etter overgang
NYC (1 525 brukere) Uken 1. april 15. april — 27. april Uken 29. april
SFO (1.600 brukere) Uken 6. mai 20. mai — 31. mai Uken 3. juni
RTP (1 275 brukere) Uken 3. juni 17. juni — 28. juni Uken 1. juli

En annen viktig faktor er å overføre brukere sammen som har avhengigheter mellom hverandre . Dette kan omfatte, men er ikke begrenset til, følgende:

BLF-overvåking

Samme jaktpilot/gruppe

Del linjer

Del av samme samtalegruppe

Bruke de samme telefonnummerene

Intercom

Admin/Leder.

Du kan se gjennom konfigurasjonen (GUI eller eksport) eller bruke verktøyet Migration Insights til å identifisere brukergruppene med disse avhengighetene.

PSTN-tilkobling

kan få tilgang til PSTN på tre måter: Cisco-anropsplaner, Cloud connect for (tidligere Cloud Connected PSTN) og lokal PSTN (lokal gateway). En enkelt plassering som definert i kan imidlertid bare tilordnes til et enkelt PSTN-alternativ.

Lokalt PSTN med en lokal gateway (LGW) er en viktig komponent i overgangsstrategien. Det gir tilkobling mellom lokal distribusjon og/eller PSTN og plattformen. støtter både Cisco og sertifiserte tredjeparts sesjonsgrensekontroller (SBC) som kan brukes som lokal gateway. For den siste listen over støttede SBC-er, se Liste over støttede SB C-er.

støtter opptil 250 samtidige anrop fra en enkelt lokal gateway som er registreringsbasert og mer enn 250 samtidige anrop fra en enkelt lokal gateway som er sertifikatbasert. Sertifikatbaserte lokale gateways kan støtte opptil 6500 samtidige anrop, men dette er basert på typen tilkobling den lokale gatewayen må ha (Over-the-Top vs interconnect peering) og SBC-modellen den lokale gatewayen distribueres på. Disse grensene er i hovedsak standard tellegrense for både lokale gateway-baserte PSTN-anrop og mellomlokalitetsanrop mellom og endepunkter. Hvis du vil ha mer informasjon, kan du se Komme i gang med lokal gateway.

Alle anrop som overskrider denne grensen avvises med en 403 forbudt. Den aktive talekommandoen for visning av anrop kan kjøres på den lokale gatewayen når som helst for å bestemme det totale antall aktive anrop.

Dårlige nettverksforhold mellom en lokal gateway og aksess-SBC kan begrense ytelsen til signalforbindelsen, noe som fører til en enda lavere grense for samti dige anrop. Enveis ventetid mellom den lokale gatewayen og datasenteret bør ikke overstige 100 ms og jitter bør være mindre enn 10 ms mens pakketap er mindre enn 0,5%.

Funksjoner og funksjonsbruk

Når du vurderer gjeldende miljø, er det viktig å identifisere og gjennomgå hvilke funksjoner som er konfigurert. I tillegg er det viktig å forstå bruken av funksjonene slik at du kan (på nytt) definere forretningsmessige og tekniske krav til distribusjonen.

Analyser konfigurasjonen for å finne ut hvilke funksjoner som er konfigurert. Dette er alle statiske data som angis når en funksjon eller innstilling er konfigurert på systemet. Følgende alternativer kan brukes til å fullføre denne analysen:

Gjennomgå konfigurasjonen i admin GUI

konfigurasjonseksport - masseeksport eller AXL

verktøy for migreringsinnsikt (anbefalt)

Cisco tredjeparts partnerverktøy (Anbefalt).

For å analysere funksjonsutnyttelse effektivt, er det viktig å undersøke dynamiske systemdata som utnyttelse, registreringer og anrop saktivitet. Ulike analytiske verktøy og dashbord gir innsikt i disse beregningene, noe som muliggjør en omfattende forståelse av system ytelse og kapasitet, noe som støtter informert beslutningstaking under migrering og optimalisering. Følgende alternativer kan brukes til å fullføre denne typen analyse:

Gjennomgang av rå CDR-poster

Gjennomgang av Unified CM RTMT-data

Migration Insights verktøy ved hjelp av CDR-data

Gjennomgang av Cloud-koblet UC-analyse i

Anropsvolum

Registrerte endepunkter

(CAC) lokasjoner

Bagasjeromsutnyttelse.

Cisco tredjeparts partnerverktøy.

Cisco anbefaler at du starter med Webex Control Hub Migration Insights-verktøyet for denne analysen. Du importerer eksport.TAR-filen og Unified CM CDR-filene (valgfritt, men nødvendig for funksjonsut nyttelsesanalyse) til verktøyet. Verktøyet vil generere følgende CSV-baserte rapporter som kan brukes til å starte analysen:

Tabell 5. Rapporter generert fra Unified CM .tar-fil
Rapportnavn
Rapportbeskrivelse
ImportedDataBulk.csv
Alle brukere og enheter fra Unified CM data
DeviceEligibility.csv
Identifiserer enheter som er kvalifisert for migrering til Webex Calling (IP-telefoner, Room OS- enheter, ATA-er og tredjepart)
DevicePoolNumbers.txt
Liste over alle tall i en bestemt enhet spool
HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv
Detaljer om enheter og brukere som bør migreres sammen basert på delte linjer, jakt pilot, samtalekø, anropsparkering og samtaleopptakskonfigurasjon
HuntGroupMigrationInsight.csv
Detaljert informasjon om tildelte jakt linjer, linjegrupper og tilknyttede agenter
SharedlineGroupMigrationReport.csv
Oversikt over hvordan telefonnumre (katalognumre) deles mellom brukere

Tabell 6. Rapporter generert fra Unified CM .tar og CDR. gzip-filer
Rapportnavn
Rapportbeskrivelse
FeatureUsageBasedDeviceEligibilityReport.csv
Informasjon om kvalifisering for enhetsmigrering basert på funksjonsbruken
FeatureUsageWithLastUsageDateReport.csv
Brukstall for antall ganger jaktpilot (er) og anropskø (er) er blitt kalt sammen med siste bruks dato
UserWorkspaceLastUsage.csv
Siste bruksdato for brukere og arbeidsområder for både myke klienter og hardtelefoner
DIDUsageReport.csv
DID-bruk for både tildelte og ikke-tildelte DID-er

Hvis du vil ha mer informasjon om Migreringsinnsikt-rapportene, kan du se Over føringsin nsikt.

Hvis du trenger mer informasjon om funksjonene og bruken etter å ha gjennomgått informasjonen i Migration Insights-rapportene, anbefaler Cisco å vurdere et av Ciscos tredjepartsmigreringsverktøy for partnere og/eller å gjennomgå konfigurasjonene i GUI eller i konfigurasjonseksportdataene.

Cisco-integrasjoner: Unity Connection UCCX UCCE

Talepost er en integrert del av tilbudet og er innebygd i løsningen. kan ikke integreres med en lokalbasert talepostløsning som Unity Connection eller Unity Connection Express. Videre er det ingen naturlig måte å migrere eksisterende Unity-tilkoblingstale postmeldinger eller hilsener til den opprinnelige taleposttjenesten som er tilgjengelig med. Noen av Ciscos tredjepartspartners migreringsverktøy har muligheter til å migrere noen av disse dataene. Hvis du vil ha mer informasjon om talepost for, kan du se Konfigurere og administrere innstillinger for talepost for en bruker. Webex Calling

støtter også delte talepost- og fakspostbokser. Hvis du vil ha mer informasjon, kan du se Administrer en delt talepost og innkommende faksboks for. Webex Calling

har en innebygd Auto Attendant-funksjon som er inkludert som en del av kjerneplattformen. Denne funksjonen tillater overgang av Unity Connections anropsbehandlere og automatisk ledsagerfunksjonalitet. Kontrollhub-verktøyet, Migrere funksjoner fraUnified CM, støtter migrering av Unity-tilkoblingskonfigurasjonene til Auto-Attendants. Hvis du vil ha mer informasjon om bruk av dette verktøyet, kan du se Migrering av enheter og funksjoner fra Unified CM tilWebex Calling.

Samtaleopptak

inkluderer to alternativer for samtaleopptak uten ekstra kostnad.

Webex anropsopptak

Dubber Go-opptak (partnertilbud) - en integrasjon mellom og dubber der alle innspilte medier holdes sikkert i skyen.

Inkludert opptaksalternati vtabell fremhever noen viktige funksjoner i de to samtale opptaksalternativene som er tilgjengelige uten ekstra kostnad.

Tabell 7. inkludert opptaksalternativer
Webex Double Go

Tilgjengelig for alle brukere Tilgjengelig for alle brukere

Ubegrensede opptak Ubegrensede opptak

1 års oppbevaringsperiode* 30-dagers oppbevaringsperiode

100 GB lagringsplass per organisasjon -

Compliance-ansvarlige kan få tilgang til og administrere anropsopptak -

API-er for å administrere opptak -

Administratorer kan konfigurere og administrere brukernes tilgang til sine anropsopptak
Brukere kan administrere sine egne opptak ved hjelp av User Hub og/eller Webex-appen.
Bare brukere kan få tilgang til og administrere opptakene sine
Fra dubberportalen deres.

Hvis organisasjonen din krever ekstra opptaksfunksjoner som samtale opptak, lengre oppbevaringsperioder, mer lagringsplass, AI-analyse og/eller administratortilgang, finnes det betalte tilbud eller tillegg fra både Cisco og tredjeparts opptaksleverandører. Hvis du vil ha mer informasjon om opptaksleverandører, konfigurasjoner og tilleggspartnertjenester, kan du se Administrer anro psopptak for Webex Calling.

Tredjepartsintegrasjoner

^{støtter en rekke tredjepartsintegrasjoner inkludert, men ikke begrenset til, SBC-er
for lokale gateways, IP-telefoner, intercom-telefoner, høyttaler/personsøkere, ATA, etc.} I tillegg til disse tredjepart ^sen hetene Webex Calling støtter den forskjellige tredje ^part sløsninger for kundesupport, analyse, opptak, fakturering osv. Hvis du vil ha mer informasjon om ^tredjepart sløsninger, kan du se Webex App Hub.

Tabell 4. Brukerovergangsplan etter nettsted
Bruker nettsted/plassering	Informasjon og opplæringsøkter før overgangen	Overgangsperiode	Støtte etter overgang
NYC (1 525 brukere)	Uken 1. april	15. april — 27. april	Uken 29. april
SFO (1.600 brukere)	Uken 6. mai	20. mai — 31. mai	Uken 3. juni
RTP (1 275 brukere)	Uken 3. juni	17. juni — 28. juni	Uken 1. juli

Tabell 5. Rapporter generert fra Unified CM .tar-fil
Rapportnavn Rapportbeskrivelse
ImportedDataBulk.csv Alle brukere og enheter fra Unified CM data
DeviceEligibility.csv Identifiserer enheter som er kvalifisert for migrering til Webex Calling (IP-telefoner, Room OS- enheter, ATA-er og tredjepart)
DevicePoolNumbers.txt Liste over alle tall i en bestemt enhet spool
HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv Detaljer om enheter og brukere som bør migreres sammen basert på delte linjer, jakt pilot, samtalekø, anropsparkering og samtaleopptakskonfigurasjon
HuntGroupMigrationInsight.csv Detaljert informasjon om tildelte jakt linjer, linjegrupper og tilknyttede agenter
SharedlineGroupMigrationReport.csv Oversikt over hvordan telefonnumre (katalognumre) deles mellom brukere

Tabell 6. Rapporter generert fra Unified CM .tar og CDR. gzip-filer
Rapportnavn Rapportbeskrivelse
FeatureUsageBasedDeviceEligibilityReport.csv Informasjon om kvalifisering for enhetsmigrering basert på funksjonsbruken
FeatureUsageWithLastUsageDateReport.csv Brukstall for antall ganger jaktpilot (er) og anropskø (er) er blitt kalt sammen med siste bruks dato
UserWorkspaceLastUsage.csv Siste bruksdato for brukere og arbeidsområder for både myke klienter og hardtelefoner
DIDUsageReport.csv DID-bruk for både tildelte og ikke-tildelte DID-er

Tabell 7. inkludert opptaksalternativer
Webex	Double Go
Tilgjengelig for alle brukere	Tilgjengelig for alle brukere
Ubegrensede opptak	Ubegrensede opptak
1 års oppbevaringsperiode*	30-dagers oppbevaringsperiode
100 GB lagringsplass per organisasjon	-
Compliance-ansvarlige kan få tilgang til og administrere anropsopptak	-
API-er for å administrere opptak	-
Administratorer kan konfigurere og administrere brukernes tilgang til sine anropsopptak Brukere kan administrere sine egne opptak ved hjelp av User Hub og/eller Webex-appen.	Bare brukere kan få tilgang til og administrere opptakene sine Fra dubberportalen deres.

Planlegg

Prosjektplan på høyt nivå

Migrasjonsreise - ett eller to trinn?

Alternativ 1: Enkelt trinnvis brukermigrering

Alternativ 2: Dobbeltrinns brukermigrering

Trinn 1

Trinn 2

Prosjektplan på høyt nivå

Når du utvikler en prosjektplan på høyt nivå for migrering fra til, er det viktig å etablere klare faser og milepæler som samsvarer med både forretning smål og tekniske krav. Planen bør begynne med en omfattende vurderings fase, inkludert å samle detaljerte tekniske og forretningsmessige krav, samt identifisere interessenter og definere suksesskriterier. Viktige hensyn inkluderer ressursal lokering, tidslinjeestimering, risikostyring, og kommunikasjonsstrategier for å sikre at alle parter blir informert og engasjert gjennom hele migreringen. I tillegg bør planen inkludere valideringskontrollpunkter som pilottesting og trinnvise utrullinger for å minimere forstyrrelser og tillate justeringer basert på tilbakemelding.

Eksempler på elementer som skal inkluderes i prosjektplanen er:

Definere omfanget av migrering (f.eks. hvilke brukere, enheter og funksjoner som skal overgå)

Planlegge opplæringsøkter for sluttbrukere og støtteteam

koordinere vurderinger av nettverksberedskap, og

Planlegging for cutover-aktiviteter med fallback-alternativer. Det er også viktig å integrere overholdelses- og sikkerhetsvurderinger, samt støtte- og optimaliserings faser etter migrering.

Ved å strukturere prosjektplanen med disse hensynene, kan organisasjoner bedre håndtere kompleksitet, redusere risiko og oppnå en jevnere overgang til.

Migrasjonsreise - ett eller to trinn?

krever at brukerne bruker den myke klienten for å ringe. Derfor, hvis noen brukere fortsatt bruker, har du to alternativer på når du kan flytte dem til. Du kan enten utføre en brukeroverføring i ett trinn eller en totrinnsmigrering av brukere.

Alternativ 1: Enkelt trinnvis brukermigrering

I en enkelt trinnvis migrering går brukerne over fra til samtidig som de blir overført fra Unified CM til. Dette alternativet er vanligvis for kunder med et lite antall brukere å migrere, og kan administrere å flytte både brukerens myke klient og ringetjeneste til samtidig. Figuren Brukerens anropstjeneste, myk klient og telefon migrerer til samtidig nedenfor viser denne typen migrering. Med dette alternativet vil en bruker ha følgende fullført samtidig:

Anropstjenester flyttet fra til

Telefonnumre og utvidelser flyttet fra til

Myk klient gikk over fra Jabber til - vil registrere seg til

Telefonregistrering flyttet fra til.

Brukerens ringetjeneste, myk klient og telefon migrerer til samtidig

Dette kan fortsatt være en trinnvis migrering der grupper av brukere flyttes til forskjellige tidspunkter, men når hver bruker flyttes, skjer alle disse samtidig.

Alternativ 2: Dobbeltrinns brukermigrering

Den andre tilnærmingen er en totrinnsmigrasjon. I trinn 1 blir brukere overført fra til, men fortsetter å ringe tjenester. Deretter flyttes brukerne i trinn 2 fra Unified CM til. Dette alternativet anbefales for større kunder for å administrere sluttbrukerendringene og ønsker å skille brukerens myke klientendring fra endringen av anropstjenesten. Følgende figur Overfør myk klient; deretter migrere samtaletjeneste, myk klient og telefon til Webex Calling nedenfor fremhever denne typen migrering.

Trinn 1

Myk klient overgått fra til - vil registrere seg til.

Trinn 2

Anropstjenester flyttet fra til.

Telefonnumre og utvidelser flyttet fra til.

registreringen flyttet fra til.

Telefonregistrering flyttet fra til.

Migrere myk klient; deretter migrere anropstjeneste, myk klient og telefon til Webex Calling

Dette kan fortsatt være en trinnvis migrering der grupper av brukere flyttes til forskjellige tidspunkter i begge trinnene.

Alternativet du velger avhenger av hvordan du vil administrere brukernes overgang til og. Anbefalingen er å ta det i trinn (alternativ 2). Dette lar deg minimere slutt brukerens endringer på en gang og dele innsatsen opp på forskjellige deler av prosjektet. Men hvis du foretrekker å ha brukere bare påvirket én gang, er bruk av alternativ 1 også gyldig.

Når du ser på den anbefalte reisen (alternativ 1), viser overgangsk artfiguren Jabber til Webex App på høyt nivå nedenfor overgangen på høyt nivå for trinn 1.

Jabber til Webex App overgangskart på høyt nivå

I dette trinnet blir brukere overgått fra Jabber til for alle sine samtaletjenester. Imidlertid er anropsplattformen fortsatt Unified CM og vil registrere sine samtaletjenester til. Som vist i overgangskartet på høyt nivå fra Jabber til Webex App endres ikke den lokale infrastrukturen, og fungerer på samme måte som Jabber gjør. Den eneste endringen er at det krever en tilkobling ut til.

Hvis du vil ha mer informasjon om denne overgangen, kan du se Jabber til Webex overgangskart og distribusjonsveil edning under Klient-delen på siden Samarbeidsovergang.

Unified CMtil over Webex Calling gangskart figur på høyt nivå er over gangen på høyt nivå fra til. Dette er trinn 2 av den anbefalte reisen.

Unified CMtil overgang Webex Calling skart på høyt nivå

Hvis du bestemmer deg for å bruke enkelttrinnsmetoden, gjelder dette også.

I dette trinnet blir brukere overført til i grupper. På dette tidspunktet begynner brukerne å bruke for sine samtaletjenester, anropsregistrering og IP-telefonregistrering.

Siden brukere beveger seg i grupper, vil Enterprise-brukere bli delt mellom de to anrops plattformene under overgangen. Fase 1 inn Unified CMtil over Webex Calling gangskartfigur på høyt nivå viser denne tilstanden. I løpet av denne fasen er det nødvendig med planlegging for hvordan man administrerer samtaler mellom brukere på de to plattformene og hvordan PSTN-anrop vil bli rutet. Hver gang en gruppe brukere blir overført til, kreves det oppdateringer for oppringingsplaner og samtaleruting på, og den lokale gatewayen (e).

Når alle brukere, myke klienter og enheter er overført til (fase 2), kan all lokal UC-infrastruktur fjernes og tas ut av drift.

Utforming

Regionvalg

Steder

PSTN

Oppringingsplan

Lokal oppringingsplan i

oppringingsplan

Opptak

1. Valg av leverandør av samtaleopptak

2. Regionvalg

Nødanrop

Lisensiering

Manuell tildeling gjennom

Automatiske lisenstildelingsmaler

Massetildeling gjennom CSV-mal

API-basert oppgave

Lisenskrav

Brukerklargjøring

Brukergrupper

Anbefalt tilnærming når du migrerer fra til

Utforming av brukergrupper

Enkel pålogging (SSO)

Støtte for flere IdP

1. Fusjoner og oppkjøp

2. Flere uavhengige IT-avdelinger

3. Ulike brukergrupper eller domener

4. Støtte for ulike autentiseringsprotokoller

5. Forbedret sikkerhet og samsvar

6. Forenklet brukeropplevelse

Duo MFA med SSO for

Funksjoner

Automatisk ledsager

Ring Park

Henting av anrop

Anropskø

Jaktgruppe

Driftsmoduser

Personsøkingsgruppe

Opptak

Enkeltnummerrekkevidde

Talepostgruppe

Regionvalg

er tilgjengelig globalt og leveres fra redundante datasentre i flere regioner: USA (Dallas, Chicago), Canada (Vancouver, Toronto), Europa (Frankfurt, Amsterdam), Storbritannia (London, Manchester), Australia (Melbourne, Sydney), Japan (Tokyo, Osaka), Saudi-Arabia (Riyadh, Jeddah) og India (Mumbai, Chennai). Medie-POP-ene tilbyr medietjenester for å optimalisere medienes rundturtider. Singapore-datasenteret brukes for eksempel til å optimalisere media tur- returtider for kunder i asiatiske land der tur-returtidene til enten Australia eller Japan- regionen kan være suboptimale. Datasentrene er sammenkoblet av en multi-gigabit og fullt redundant ryggrad. Figuren globalt distribuerte datasentre viser en oversikt over alle datasentre. For den siste listen over tilgjengelige datasentre, se Datasenterlokasjoner for Webex Calling.

Globalt distribuerte datasentre

Hver kunde er klargjort på en av forekomstene. All klargjøringsinformasjon for den kunden lagres i den forekomsten, og SIP-signaleringen for alle endepunkter og lokale gateways som er klargjort for den kunden, er knyttet til forekomsten kunden er klargjort på. Fordi det er vanskelig å endre det første regionvalget, er det viktig å vurdere alle relevante faktorer som en del av beslutnings prosessen som fører til regionvalg. For å unngå overdreven signalering rundtursforsinkelse, er det viktig å bestemme tidlig i overgangsprosessen hvilken forekomst som skal brukes. Cisco anbefaler å velge forekomst som gir de laveste signaleringstidene for det største antallet brukere i distribusjonen.

For tilgjengelighet i land, se Hvor er Webex tilgjengelig? .

Steder

For å forberede klargjøring av lokasjoner, må den nødvendige informasjonen for alle overføringssteder samles inn. Informasjonen som trengs for hvert sted er oppsummert i Informasjon som skal fanges for hvert sted.
Tabell 1. Informasjon som skal innhentes for hvert sted
Informasjon Kommentar
Utvidelsesområde (er) Hvert sted i kan ha utvidelser som starter med forskjellige sifre. Ett siffer må spares for styr ingssifferet mellom lokalene (for eksempel 8) og ett for PSTN- styresifferet (for eksempel 9). Ingen utvidelsesområde kan starte med noen av disse to sifrene.
Alle utvidelsesområder på alle steder må være like lange.
DID-område (er) -
PSTN styringssiffer -
Nettstedskode Alle nettstedskoder for alle steder må være unike og ha samme lengde.
Hovednummer Når du oppretter et sted, må to DID-er klargjøres. Ett som hovednummer (for eksempel for å tilordnes en automatisk svartjeneste) og ett for telefonsvar erportalen.
Bestem en DID for telefonsvarernummeret.
Talepostnummer
Antall lisenser Nødvendige lisenser etter type inkludert Standard, Professional, Workspace, Ruteliste, Utgående anropsplan.
Samtidige samtaler i den travle timen Summen av samtidige samtaler mellom enheter og mellom enheter og den lokale gatewayen (PSTN og anrop til enheter). Nødvendig for å bestemme den nødvendige båndbredden til internettilgang.
Land -
Tidssone -
Språk -
Kontakt (Navn, Telefon, E-post) -
Adresse (Gateadresse, by, stat, postnummer) -
Nødetjenestens fysiske utsendelsessted for endepunkter Enhetsforsendelsessted som brukes til nødanrop inkluderer vanligvis følgende: bygningsadresse, bygningsadresse + etasjenummer, bygningsadresse+ suitenummer eller bygningsadresse + etasjenummer+kontor/kubisk nummer.
Per enhet unik fysisk nettverksplassering for nødetjenester Fysisk nettverksplassering for nødanrop inkluderer vanligvis følgende: svitsj/bryterport for kablede enheter, BSSID-er (Basic Service Set Identifiers) for trådløst tilkoblede enheter og/eller lokale IP-delnett (er) for endepunktsenheter.

PSTN

Når kundene designer en distribusjon, har kundene tre primære PSTN-tilkoblingsalternativer: Cisco C alling Plans (en skylevert PSTN-tjeneste administrert av Cisco), Cloud Connec ted PSTN-leverandører (CCPP, der leverandører leverer PSTN-tjeneste gjennom skyen) og lokal PSTN (der lokale gateways kobler bedriftsnettverket til PSTN). Med introduksjonen av PSTN-trunking for hybriddistribusjoner (for mer informasjon, se PSTN-trunking for hybriddistribusjoner ved PSTN-trunking), Webex Calling får organisasjoner ekstra fleksibilitet i migreringstilnærmingen. Denne funksjonen gjør det mulig for kunder å flytte PSTN til CCPP ved starten av overgangs reisen og begynne å gå over til skybasert PSTN for brukere, samtidig som de utnytter CCPP for å opprettholde PSTN-tjenesten for brukere som forblir på Cisco under en trinnvis migrering.

Denne hybride tilnærmingen gjør det mulig for organisasjoner å flytte utvalgte brukergrupper til skyen først, uten å umiddelbart revidere hele telefonimiljøet. Det introduserer imidlertid ytterligere kompleksitet og risiko, spesielt rundt tilpasning av eksisterende samtalerutingslogikk for å støtte den nye arkitekturen. Interoperabilitet med eldre applikasjoner, for eksempel faksservere, kontaktsentre eller personsøkings systemer, krever også nøye vurdering. Viktige tekniske utfordringer kan omfatte å sikre sømløs ende-til-ende-kodeforhandling og DTMF-signalering (Dual-Tone Multi-Frequency) på tvers av det blandede miljøet, samt validering av kompatibilitet med spesialiserte telefonfunksjoner. Rik tig planlegging og testing er avgjørende for å minimere forstyrrelser og opprettholde pålitelige taletjenester gjennom hele migreringsprosessen. I tillegg er kommersielle hensyn viktige, ettersom hybrid trunking krever en bruks lisens som er basert på antall samtidige anrop mellom det lokale miljøet og Cloud Connected PSTN Provider (CCPP).

Alternativt kan organisasjoner velge å beholde sin lokale PSTN-tilkobling gjennom hele overgangsfasen. I dette scenariet kan migrering til CCPP utføres på to måter: som en enkelt, koordinert cutover for alle brukere og steder når overføringen er fullført, eller trinnvis, med PSTN-migrering som skjer per sted når brukerne flyttes til. Denne tilnærmingen kan bidra til å effektivisere sameksistens og opprettholde kontinuitet for eldre integrasjoner, men den introduserer flere operasjonelle kompleksiteter. Blant disse er utfordringer knyttet til nummerportering, slik som behovet for presis koordinering av antall portordrer, potensielle forsinkelser, og leverandørpålagte begrensninger som et tak på antall samtidige portforespørsler eller begrensninger på portering av delsett av store antall blokker. Organisasjoner må nøye planlegge sin PSTN-overgangsstrategi, ta hensyn til disse logistiske hensynene for å unngå tjenesteavbrudd og sikre en jevn migreringsopplevelse.

Overføring til CCCP i starten kontra å beholde lokalt PSTN

Figuren Migrering til CCCP i starten kontra å beholde lokalt PSTN viser de to PSTN-overføring salternativene som er forklart ovenfor. Illustrasjonen til venstre viser scenariet der alle lokale brukere og programmer bruker Cloud Connec ted PSTN-tjenester gjennom en lokal koffert og en lokal gateway som ko bler den lokale gatewayen til, mens illustrasjonen til høyre viser scenariet der eksisterende lokale PSTN forblir på plass og brukere bruker lokal PSTN gjennom den lokale gateway-tilkoblingen mellom Webex Calling lokale enheter og. Under overgangen kan plasseringer byttes til å bruke Cloud Connected PSTN.

I begge scenariene bruker samtaler mellom lokal og bruker den lokale gateway-tilkoblingen. Forbindelsen mellom lokalt og må utformes og dimensjoneres tilsvarende basert på forventet antall samtidige samtaler og nødvendig redundans.

Oppringingsplan

For å oppnå sømløs interoperabilitet mellom og i løpet av migreringsperioden, må en omfattende nummerplanarkitektur utvikl es og implementeres på tvers av begge plattformene. Denne utformingen av nummerplanen med to plattformer sikrer konsekvent samtaler uting, nummeroversettelse, og funksjonens gjennomsiktighet, slik at brukere på begge systemene kan kommunisere uten tjenesteforringelse eller forstyrrelser i brukeropplevelsen gjennom sameksistensfasen.

Lokal nummerplan i

Under overgangen for å tillate sameksistens av enheter som er registrert på Unified CM og på bedriften, må nummerplanen endres slik at minst følgende krav kan oppfylles:

+E.164 ringer fra til

Utvidelsesoppringing fra til (internt på stedet, men også mellom steder hvis utvidelsesområdene er unike)

Forkortet oppringing mellom nettsteder fra til

Tvunget oppringing på nettet fra til

Tilbakringning fra katalogen for ubesvarte anrop til destinasjoner på

PSTN-anrop fra til PSTN hvis det brukes lokalt PSTN under overgangen

PSTN-anrop fra til hvis under overgangen PSTN-trunking for hybriddistribusjoner brukes til å gi PSTN-tilgang til lokale brukere gjennom Cloud Connect for

Tvunget på nettet fra til

Utvidelsesoppringing fra til (mellom nettsteder).

Hvis noen av de ovennevnte ikke støttes oppringingsvaner før overgangen, for eksempel ikke eksisterer noen forkortet innringingsvane mellom steder, trenger de ikke nødvendigvis å innføres under overgangen.

Figur Oppringings planen for beste praksis viser fremgangsmåten for oppringingsplan som beskrevet i Preferred Architecture for Cisco Collaboration 12.x Enterprise On-Premises Deployments, CVD. Viktige egenskaper ved denne tilnærmingen inkluderer:

Enkel partisjon for+E.164 katalognumre

Kjerneruting basert på+E.164 rutemønstre

Normalisering av alle oppringingsvaner til+E.164 ved hjelp av oversettelsesmønstre

Bruk av oversettelsesmønster som kaller søkeromsarv (alternativ Bruk opphavsmannens anro pssøkeområde angitt på oversettelsesmønstre).

Oppringingsplan for beste praksis

For eksempel vil PSTN-oppringing (9+1+10D) fra en enhet i SJC som er utstyrt med linjeanropssø keområde SJCinternational først bli matchet av 9.1 [2-9] XX [2-9] XXXXXX-oversettelsesmønsteret som normaliserer det oppringte partnummeret til +E.164. Det sekundære oppslaget bruker deretter det samme anropssøkeområdet SJCinternational igjen (anrop av søkeromsarv) og +E.164-sifrede strengen vil enten bli matchet av et +E.164 katalognummer i DN-partisjonen eller av et av PST N- rutemønstrene i USPSTNNational- eller SJCPSTNLocal-partisjonen. Forkortede samtalevaner innenfor og mellom steder implementeres av oversettelsene i ESN- og SJCTO E 164-partisjonen. Mens ESN- partisjonen er en global partisjon (tilgjengelig for telefoner på alle steder), er SJCTOE16 4-partisjonen bare tilgjengelig for brukere på stedet SJC. Dette forutsetter overlappende utvidelsesområder.

Det første trinnet for å aktivere anrop fra til er å sørge for at +E.164-destinasjoner blir rutet tilsvarende. Dette kan oppnås ved å legge til en skillevegg til nummerplanen, legge til +E.164 rutemønstre for alle destinasjoner til denne partisjonen, og til slutt legge partisjonen til alle anropende søkerom som representerer tjenesteklasser som må kunne nås. Oppretting av en dedikert partisjon er nødvendig for å muliggjøre opprettelse av en differensiert tjenesteklasse for samtaler som stammer fra. For å unngå anropsløyfer bør det innkommende anropssøkeområdet på bagasjerommet fra den lokale gatewayen ikke ha tilgang til partisjonen.

+E.164 ruting til Webex Calling

Som vist i fig. +E.164 ruting tilWebex Calling, for å muliggjøre ruting fra til for et sted med +E.164 DID-område +1 221 555 2XXX og stedskode 121, må et presserende rutem ønster som samsvarer med dette +E.164-området legges til partisjonen.

Hvis det ikke kreves et stedsspesifikt valg av lokal gateway, kan det i stedet for å bruke en ruteliste med en lokal rutegruppe som mål for rutemønstre som peker på en enkelt rutegruppe klargjøres med den lokale gatewayen som eneste medlem, og deretter peker rutemønstrene på en enkelt ruteliste med denne ene rutegruppen som eneste oppføring.

For å muliggjøre forkortet oppringing mellom steder til stedet blir det nødvendige rutemønster 8121.2XXX lagt til partisjonen. For områder som skal overføres til et oppringingsnormaliseringsmønster 8121.2XXX som normaliserer ESN-oppringing til +E. 164, kan det allerede finnes i ESN-partisjonen. I dette tilfelle synes 8121,2XXX å være overflødig, men så snart alle DNer i den respektive lokalisering er blitt migrert over til 8121,2XXX oppringingsnormaliseringsmønsteret kan fjernes, og deretter muliggjør rutemønsteret 8121,2XXX ESN-oppringing selv for utvidelsesbrukere i det området.

Med disse oppringingsplanendringer kan anrop til stedet plasseres ikke bare ved å ringe forkortet inter-site og +E.164. Internasjonal og nasjonal PSTN-oppringing er også mulig fordi disse oppringingsvanene først blir normalisert til +E.164 gjennom de allerede eksisterende translasjonsmønstre for oppringingsnormalisering og deretter blir rutet til ved å matche rutemønsteret +E.164 i partisjonen.

+E.164-rutemønstersamsvarende på stedets DID-område kan klargjøres mens alle DID-er fremdeles er vert på. Den beste matchende mønstertilpasningsalgoritmen sørger for at når et nummer som er hostet på blir oppringt, så er +E.164-katalognummeret som er klargjort på, et bedre samsvar enn rutemønsteret +E.164 med jokertegn som peker på, slik at samtalene blir utvidet til en linje på og ikke sendt til.

oppringingsplan

Hver bruker i er utstyrt med en utvidelse og/eller et+E.164 telefonnummer. Utvidelseslengden er en fast global innstilling: alle utvidelser i en distribusjon har samme lengde. Utvidelsesoppringing kan brukes mellom brukere både innenfor et sted og mellom steder. Forkortet utvidelsesoppr inging mellom nettsteder (sistnevnte tilfelle) fungerer bare hvis den oppringte utvidelsen er unik.

Hvis forkortet oppringing mellom steder er et krav, men det er overlapp mellom utvidelser som er tildelt på forskjellige steder, må det opprettes en bedriftsspesifikk nummereringsplan ved å prefikse utvidelsene med en tilgangskode, en områdekode. Hvis du vil ha mer informasjon, kan du se Foretrukket arkitektur for Cisco Collaboration 15 Lokale distribusjoner, Designoversikt tilgjengelig på Ciscos foretrukne arkitekturer for samarbeid.

Utvidelseslengden, oppringingingsvirkemåten mellom lokaliseringsutvidelsene, prefikslengden for oppringing mellom lokaliseringene og styresifferet i rutingprefikset for interlokasjonsoppringing er konfigurert i innstillingene for anropstjenesten i:

Prefiksl@@ engde for posisjonsrut ing: Prefikslengde inkludert styresifret. Kreves bare hvis en bedriftsnummerplan må etableres som alternativ forkortet foretaksoppringingsvane mellom lokaliseringer.

Styresiffer i rutingprefiks: Styresiffer for forkortet foretaksoppringingsvane mellom lokaliseringer. Overlapping med første siffer på et hvilket som helst sted og sted utgående nummersiffer bør unngås. Kreves bare hvis en bedriftsnummerplan må etableres som alternativ forkortet foretaksoppringingsvane mellom lokaliseringer.

Intern forlengelseslengde: Standard lengde på forlengelser. Kan være en hvilken som helst verdi mellom to og ti.
Når en lokal anropsstyring krever telefonoppringing eller oppringing ved hjelp av betydelige foretaksnumre (styringskode, områdekode, utvidelse) fra en lokal anropskontroll til og den lokale anropskontrollen sender en utvidelse som anrops-ID, må du også angi parameteren Maksimal ukjent utvidelseslengde i delen Anropsruting mellom og lokaler for å sikre at oppstrøms anrop fra den lokale anropskon trollen til kan klassifiseres som lokale anrop på riktig måte.

Tillat utvidelsesoppringing mellom steder: By tt for å aktivere/deaktivere utvidelsesoppringing mellom steder. Dette alternativet skal bare aktiveres hvis alle utvidelser i organisasjonen er unike. Hvis alternativet er deaktivert, må bedriftssignifik ante tall (styringskode, områdekode, utvidelse) eller telefonnumre ringes mellom steder.

De tre første parametrene brukes hovedsakelig til å bygge en oppringingsplan for telefoner for å minimere mellom sifrede tidsavbrudd når du bruker off-hook oppringing. Avvik fra disse globale innstillingene er fortsatt mulig (Eksempel - utvidelser med en annen lengde kan klargjøres), men en advarsel vises i Control Hub, og oppringing fra telefoner kan kreve blokkert oppringing for å unngå konflikter i den for håndsinnlastede nummerplanen.

Tabellen Enterprise-nummerering seksempel viser et eksempel på tre steder der ut videlsesområdene til to steder, NYC og RTP, er identiske. Etablering av et bedri ftsnummereringsskjema med styringssiffer 8 mellom steder, etterfulgt av en tresifret nettstedskode, og den firesifrede utvidelsen skaper en ikke-overlappende forkortet oppringingsvane mellom nettsteder.

Tabell 2. Eksempel på bedriftsnummerering
Nettstedet Utvidelsesområde Nettstedskode Enterprise-utvalg

NYC 2XXX 202 8 202 2XXX

SFO 3XXX 203 8 203 3XXX

RTP 2XXX 204 8 204 2XXX

For å muliggjøre en jevn overgang bør settet med oppringingsvaner for brukere før og etter overgang til ideelt sett være det samme. For å forberede overgangen for hvert sted må DID-områdene og utvidelsesområdene (eller forkortede samtalevaner på stedet) dokumenteres. Bas ert på denne informasjonen, må styringssifferet mellom steder velges.

Tabellen F aste lengdeforlengelsesområder viser et eksempel på tre steder og forlengelses områder med fast lengde. Fordi overlappende oppringingsvaner må unngås, er det viktig å sørge for at det første sifferet i rekkevidden ikke stemmer overens med styresifferet for forkortet oppringing mellom steder for et hvilket som helst utvidelsesområde. Hvis for eksempel 8 er valgt som styringssiffer for oppringing mellom steder, da kan ingen utvidelsesområde på noe sted starte med 8. Vanligvis samsvarer utvidelsene på et gitt sted med de siste sifrene i DID-ene som er tildelt det stedet. For å unngå konflikter kan det første sifferet i utvidelsen endres. Hvis for eksempel DID-er i +1 408 555 8XXX-området brukes på et sted, kan 7XXX i stedet for å bruke 8XXX som utvidelsesområde brukes for utvidelsene på det området

Tabell 3. Faste lengdeforlengelsesområder
Nettstedet Utvidelsesområde Utvidelser Nettstedskode Enterprise-utvalg

NYC 2XXX 2XXX 202 8 202 2XXX

SFO 8XXX 7XXX 203 8 203 7XXX

RTP 1XX 11XX 204 8 204 11XX

Syvsifrede oppringingsstrenger som er oppringt på en enhet som bruker den amerikanske nummerplanen, overlapper med et syv-sifret mønster for lokal oppringing i den forhåndsinnlastede amerikanske nummerplanen. For å unngå overlapping mellom oppringingsvaner på nett og utenfor nettet (PSTN), kan en obligatorisk ekstern tilgangskode brukes på det stedet. Hvis det eksisterende bedriftsnummereringsskjemaet og den tilsvarende forkortede innbyrdes oppringing overlapper med mønstre i den nasjonale nummereringen, kan det under overgangen til nummereringsskjemaet for å unngå overlapping også endres til en lengre eller kortere form. Den enkleste måten å oppnå dette på er å legge til et ekstra polstringssiffer i nummereringsskjemaet. Det nye lengre oppringingsskjemaet mellom nettsteder trenger bare å bli tatt i bruk av brukere som allerede er migrert til. Brukere som fortsatt er på, kan fortsette å ringe syv sifre. Bedriftsoppringingsplanen på må i dette tilfellet sørge for at forkortet syvsifret oppringing fra Unified CM til blir omgjort til enten +E.164 eller til det forkortede oppringingsformatet som er distribuert på. Dette må gjøres før du sender anropet til den lokale gatewayen.

Table Transitioning syv-sifret oppringing viser et eksempel på denne omnummereringen. I dette eksemplet bruker forkortet innbyrdes oppringing på styringssiffer 8 etterfulgt av en tosifret nettstedskode og en firesifret utvidelse. For å unngå syv-sifret forkortet innbyrdes oppringing for steder på, kan stedskodene lett endres til tre sifre ved å prefiksere et vilkårlig utfyllingssi ffer (8 i eksemplet) til de tosifrede stedskodene som brukes i, slik at oppringing mellom steder fra telefoner bruker styringssiffer 8 etterfulgt av polstringsifferet 8, den gamle tosifrede stedskode og den firesifrede forlengelse. Brukere på trenger ikke å huske nye nettstedskoder; de trenger bare å huske å bruke 88 som prefiks for oppringing mellom nettsteder i stedet for 8 på.

Tabell 4. Overgang av syv-sifret oppringing

Nettstedet Utvidelser Nettstedskode Enterprise-utvalg 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 scenario med forskjellige virksomhetsnummerformater på, og hvis bedriftsnumre presenteres som informasjon om anropende part for samtaler fra til (for eksempel - Anrop fra enheter uten DID), er det viktig å også implementere en kartlegging mellom de forskjellige nummerformatene for informasjon om oppringende part for å sikre at tilbakeringing fungerer. Denne kartleggingen kan oppnås ved å bruke anropspartens transformasjonsmønster på stammen mellom og den lokale porten.

Opptak

En velutviklet løsning for samtaleopptak krever nøye vurdering av flere viktige designelementer for å sikre at den stemmer overens med organisatoriske mål, regulatoriske krav og tekniske begrensninger. To av de mest kritiske beslutningene involverer valg av leverandør og regionvalg, som begge må skreddersys globalt og overstyres på bestemte steder, basert på forretningsbehov.

1. Valg av leverandør av samtaleopptak

Å velge riktig leverandør av samtaleopptak er grunnleggende for å oppfylle forretning smål og sikre funksjonstilpasning på tvers av organisasjonen:

Globalt leverandørvalg: Organisasjoner utpeker vanligvis en primær leverandør av samtale opptak på globalt nivå, noe som sikrer konsistens i funksjonssett, samsvar og støtte på tvers av alle lokasjoner

Stedsbaserte overstyringer: I scenarier der bestemte områder eller regioner har unike forretningsbehov eller forskriftskrav, kan det være nødvendig å overstyre det globale leverandørvalget og spesifisere alternative leverandører for disse stedene. Denne fleksibiliteten støtter varierende overholdelsesmandater og lokale operasjonelle behov

Forretningskrav: Valget av leverandør bør drives av en vurdering av virksomhetsdrivere som overholdelse av forskrifter (eksempel - MiFID II, HIPAA), kvalitetssikring, tvisteløsning eller opplæringsbehov

Tilgjengelighet av funksjoner: Leverandører bør evalueres basert på deres evne til å levere nødvendige funksjoner, for eksempel sanntidsovervåking, søke- og avspillingsfunksjoner, kryptering, oppbevaringspolicyer, integrering med analyseplattformer og støtte for forskjellige samtaletyper (innkommende, utgående, interne).

2. Regionvalg

Det er avgjørende for samsvar og ytelse å bestemme regionen der anropsopptak lagres og behandles:

Globalt regionvalg: Som standard kan organisasjoner velge en enkelt region for lagring av anropsopptak for å forenkle administrasjon og styring

Stedsbaserte regionoverstyringer: Når lover om dataopphold eller bedriftspolicyer krever det, kan det være nødvendig å overstyre den globale regioninnstillingen for bestemte steder, og sikre at anropsopptak lagres og behandles innenfor de nødvendige geografiske grensene

K@@ rav til dataopphold: Utformingen må ta hensyn til internasjonale og lokale databeskyttelsesforskrifter (for eksempel GDPR, CCPA eller landsspesifikke mandater) som kan diktere hvor og hvordan samtaleopptak oppbevares.

Et annet kritisk aspekt som skal tas opp under planleggingen og utformingen av en anropsopp taksløsning for, er estimering av lagringsbehov. Det er viktig å forutsi lagringsbehov nøyaktig for å sikre at tilstrekkelig kapasitet er tilgjengelig for å støtte pågående forretnings drift, opprettholde samsvar og unngå tjenesteforstyrrelser.

Flere viktige parametere bør vurderes når du bestemmer forventet lagringsbehov:

Volum av innspilte samtaler: Vurder det forventede antallet samtaler som vil bli tatt opp innen et gitt tidsintervall (f.eks. per dag, uke eller måned). Dette inkluderer ikke bare eksterne samtaler, men også intern kommunikasjon, hvis det kreves av forretningspolitikk eller regulatoriske mandater

Gjennomsnittlig samtalevarighet: Beregn den typiske lengden på innspilte samtaler, ettersom lengre samtaler vil forbruke mer lagringsplass. Variasjoner i samtalens varighet på tvers av ulike avdelinger eller brukergrupper bør også tas med i estimatet

Oppbevaringsperiode: Definer hvor lenge opptakene må beholdes, noe som ofte er diktert av organisasjonspolitikk eller eksterne forskrifter (for eksempel bransjespesifikke samsvarsstandarder). Lengre oppbevaringsperioder vil øke det totale lagringskravet

Vekstanslag: Vurder forventet vekst i samtalevolum eller utvidelse av registreringsomfanget, som kan skyldes virksomhetsskalering, nye regulatoriske krav eller introduksjon av flere brukere eller lokasjoner.

Ved å analysere disse parametrene grundig, kan organisasjoner utvikle en robust lagringsstrategi som sikrer skalerbarhet, kostnadseffektivitet og overholdelse av forskrifter for samtaleopptaksløsningen. Det anbefales også å regelmessig gjennomgå og justere lagringstildelinger etter hvert som bruksmønstrene utvikler seg over tid.

Nødanrop

Kravet om å dirigere et nødanrop til det aktuelle utsendelsessenteret er et krav for enhver anropstjeneste som tilbyr PSTN-tjeneste. Med er rutingen av nødanrop hjemmehørende i løsningen og inkluderer støtte for alle nasjonale nødnumre i landene som støtter. Rutingen av et nødanrop inn er basert på plasseringen som er definert innenfor og PSTN-tilgangsmetoden for lokasjonen. Nødnumrene i er forhåndsdefinerte og spesifikke for landet brukerne og enhetene er distribuert i.

Det er to metoder for å levere nødanrop. Det er en grunnleggende rutetjeneste for nødanrop og en forbedret rutetjeneste for nødanrop. Den grunnleggende rutetjenesten for nødanrop vil bruke et administratorvalgt nummer for å identifisere plasseringen og anropsruten for å nå nødetatene. For grunnleggende nødanrop er anropsbanen vanligvis gjennom kundens PSTN-alternativ for det stedet. har også forbedret ruting av nødanrop designet for distribusjoner i USA og Canada som har forskriftskrav som krever bruk av en landsdekkende leverandør for å levere nødanrop til riktig utsendelsessenter.

Alle kunder bør i det minste distribuere den grunnleggende konfigurasjonen for nødanrop. Grunn leggende nødanrop krever at minst ett kundeeid +E.164-nummer tildeles hvert sted som er definert i. For grunnleggende nødanrop vil hvert sted være definert av en gateadresse som politi, brann- eller ambulansetjenester sendes til i nødstilfeller. I de fleste tilfeller er hovednummeret for stedet det beste valget for å representere den fysiske plas seringen av nødsituasjonen. Vanligvis er tildelingen av adressen til+E.164-nummeret koordin ert med PSTN-leverandøren. Bildene nedenfor viser tildelingen av hoved nummeret som skal brukes som nødnummer for Richardson-stedet.

Plassering ECBN-konfigurasjon

I de fleste situasjoner er en bygningsadresse tilstrekkelig for forsendelsesadressen for stedet. Men hvis ytterligere posisjonsdetaljer er nødvendig for bestemte brukere eller enheter, kan en administrator bruke den samme prosessen som beskrevet ovenfor og tilordne disse enhetene til en bestemt adresse eller en mer presis plassering inne i adressen (som et gulv eller et rom). I Brukeradministras jon i tillater kategorien Anrop at et bestemt nummer kan brukes for en bruker og deres enheter for å få spesifikk utsendelsesadresse. Følgende bilder illustrerer hvordan et bestemt nummer kan tilordnes til en enhet. Administratoren er ansvarlig for å sørge for at nummeret som brukes av enheten, har riktig utsendelsesadresse tildelt den. Adres setildelingen gjøres vanligvis gjennom PSTN-leverandøren av det stedet.

Bruker ECBN-konfigurasjon

For USA-baserte telefonidistribusjoner som må tilby forbedrede nødanrop sløsninger, bruker RedSkys Horizon Mobility integrert i for ruting av nødanrop. Når du bruker RedSky for samtaleruting, må en administrator registrere seg for en konto gjennom Cisco og konfigurere riktig informasjon i C alling -> Service Settings for å aktivere denne funksjonen. Når RedSky- tjenesten er aktivert på systemnivå, vil en administrator aktivere RedSky- tjenesten på hvert posisjonsnivå. Aktivering av forbedret nødanrop på et sted vil aktivere tjenesten for alle enheter som er tilordnet det stedet. Enheter som støtter forbedret nødanrop er Cisco MPP-telefoner, Cisco PhoneOS-telefoner og Ciscos.

Det er to innstillinger for å aktivere forbedret nødanrop på et sted. Tillat RedSky å motta nettverkstilkoblingsinformasjon og testanrop bør brukes til å bekrefte at RedSky-konfigurasjonen for enhets- og infrastrukturtilordninger er riktig. Denne innstillingen gjør det også mulig å plassere testanrop til 933 for å utføre posisjons verifisering ved hjelp av RedSkys IVR-system for å lese ut plasseringen til den som ringer. Selv om dette dokumentet ikke dekker RedSky-konfigurasjonen for posisjonssporing, bør en administrator ALLTID teste stedsoppdagelsen før du aktiverer nødan rop for å rute til RedSky. Når testingen er fullført og bekreftet som nøyaktig, vil administratoren rute samtaler til RedSky ved å bytte rutens nødanrop til RedSky. Denne bryteren vil dirigere alle nødanrop for stedet til RedSky for levering til telefonsvareren for stedet.

Innstillingene for forbedret nødanrop gjelder også for klienter både lokalt og eksternt. Når det er lokalt, kan det spores på samme måte som skrivebordstelefoner spores. Når den er utenfor stedet, vil brukeren kunne angi plasseringen dynamisk direkte i. Hvis du vil ha mer informasjon om nødanrop, kan du se Forbed ret nødanrop for.

Lisensiering

Det er flere alternativer for å tilordne lisenser til brukere.

Manuell tildeling gjennom

Administratorer tilordner lisenser manuelt til individuelle brukere gjennom grensesnittet.

Administratorer kan redigere tjenestelisenser for individuelle brukere og tilordne anropslisenser direkte.

Automatiske lisenstildelingsmaler

Bruk lisenstildelingsmaler til å automatisk tilordne lisenser til brukere basert på gruppe- eller organisasjonsinnstillinger.

Automatisk lisensiering kan gjøres ved hjelp av katalogsynkronisering eller manuelle brukeroppdateringer, men brukerne må ha et gyldig+E.164-formatert telefonnummer og telefonnumrene må eksistere på et sted før brukerklargjøring. Hvis betingelsene ikke er oppfylt (f.eks. ugyldig telefonnummer format), tildeles ikke lisenser.

Massetildeling gjennom CSV-mal

Last opp en CSV-fil med brukerdetaljer og lisenstildelinger for å legge til eller endre flere brukere samtidig.

CSV-import støtter å legge til opptil 20 000 brukere og tilordne lisenser, men lisenser krever spesifikke felt som telefonnummer og utvidelse.

API-basert oppgave

Bruk API-er til å programmatisk tilordne lisenser og administrere brukere.

støtter API-operasjoner for bruker- og lisensadministrasjon (People, SCIM 2.0 og Licenses APIer), som kan utnyttes for automatisering av lisenstildeling. Lisens- API-en tillater samtidig tildeling av lisenser, telefonnumre og utvidelser.
Tabell 5. Brukerklargjøringsalternativer - sammendrag
Oppgavemetode Fordeler Ulemper
Manuell gjennom Enkelt for få brukere.
Tillater presis og detaljert kontroll over lisenstildeling.
Ikke skalerbar, tidkrevende
Utsatt for menneskelige feil under manuell oppføring.

Automatiske lisensmaler Skalerbar
Reduserer manuelle feil
Kan brukes på nye og eksisterende brukere.
Krever gyldige telefonnumre og steder.
Mer komplisert å sette opp
Krever også brukergrupper per gruppe brukere med tilsvarende lisensieringskrav.

Masseopplasting av CSV Effektiv for store brukersett
Tillater samtidig tildeling av lisenser, telefonnumre og utvidelser.
Krever nøye CSV-formatering
Potensial for feil hvis telefon numre eller utvidelser mangler eller er feil.
API-basert oppgave Automatiserbar, fleksibel.
Tillater samtidig tildeling av lisenser, telefonnumre og utvidelser.
Krever utvikling og API-kunnskap.

Tabellen Brukerklargjøringsalternativer - sammendrag oppsummerer brukerklargjøringsalternativer og fordeler og ulemper. Denne oversikten hjelper deg med å velge den beste lisenstildel ingsmetoden basert på kundeorganisasjonsstørrelse, automatiseringsfunksjoner og brukerklargjørings prosesser og krav.

Der det er mulig anbefaler Cisco å tilordne anropslisenser ved hjelp av lisensmaler. Dette krever at for hver gruppe brukere som krever et unikt sett med lisenser (Eksempel - Standard vs. Profesjonell) eksisterer en gruppe med de respektive gruppemedlemskapene. Som beskrevet i Brukergrupper- seksjonene, kan brukergrupper defineres manuelt i eller synkroniseres fra en bedriftskatalog. En kombinasjon av begge tilnærmingene er mulig.

Brukere som tilhører flere grupper, får lisenser fra alle oppgaver som brukes på alle gruppene deres. Dette gjør det mulig å bruke lisensspesifikke sikkerhetsgrupper i bedriftskatalogen til å administrere lisenstildeling der den resulterende brukerlisenstildelingen styres av foreningen av gruppemedlemskap.

Hvis du vil ha mer informasjon, kan du se Konfigur ere automatiske lisenstildelinger i Control Hub og Konfigurere automatiske lisenstildelingsmaler for Webex Calling brukere.

Lisenskrav

Denne delen dekker bare relaterte lisenser. Andre lisenstyper (Eksempel - Webex-enhetsregistrering, meldinger, møter) dekkes ikke. Som en del av designprosessen må lisenskravene bestemmes. Lisenstall for følgende lisenstyper må beregnes:

Standard: antall individuelle brukere som krever standard telefonfunksjoner.

Profes jonell: antall brukere og arbeidsområder som krever avanserte telefon funksjoner. Virtuelle linjer og gruppepost har rett til et 1:1 -forhold for hver profesjonell lisens. Derfor, i sjeldne tilfeller der antallet nødvendige virtuelle linjer eller gruppebeskjeder overstiger antall brukere og arbeidsområder som krever avanserte telefonif unksjoner, må det tas hensyn til ytterligere profesjonelle lisenser.

Arbeidsområde for fellesområde: antall delt bruk eller fellesarealer som krever standard samtalefunksjoner.

Kundeservice: antall agenter og veiledere som krever Customer Assist-funksjoner. Kundeservice inkluderer Professional-lisensen.

Ruteliste-anrop: antall påkrevde Cloud Connected PSTN-anrop mellom lokale brukere og/eller lokale spesialiserte tredjepartsapplikasjoner.

Attendant Console: antall brukere som trenger tilgang til den medfølgende konsollklienten.

Cisco Calling Plan (Outbound Calling Plan): antall brukere som trenger et PSTN- nummer og/eller utgående PSTN-anropstilgang for Cisco PSTN-tjenesten.

Det er ingen dedikert lisenstype for profesjonelle arbeidsområder. Profesjonelle arbeidsområder bruker en Professional-lisens.

Arbeidsområder kun for hot-desk tilbyr hotdesking-vertstjenesten og nødanrop fra hot-desking-verten og krever ingen lisens. Hvis du vil ha mer informasjon, kan du se Legge til og administrere bare Hot Desk-enheter.

Hvis du vil finne den nødvendige lisenstypen for hver bruker og arbeidsområde basert på funksjoner som trengs, kan du se Funksjoner tilgjengelig etter lisenstype for Webex Calling.

For å skille mellom funksjonalitet som tilbys av samtalekøer kombinert med den profesjonelle lisensen i motsetning til kundestøtte, se sammenligning av Webex Calling samtal ekø og kundestøtte.

Brukerklargjøring

Når du klargjør brukere i Webex, er det flere tilgjengelige alternativer, som hver passer til forskjellige organisasjonsbehov og miljøer:

Manuell klargj øring: Administratorer kan legge til og administrere individuelle brukere direkte innenfor. Denne metoden er grei, men best egnet for små organisasjoner eller begrensede bruker endringer.

Masseklarering gjennom CSV: For større brukerbaser kan administratorer importere og oppdatere brukere i bulk ved å laste opp CSV-filer til. Dette muliggjør effektiv styring av opptil tusenvis av brukere samtidig.

Alternativer for katalogsynkronisering:
Directory Connector: Dette er et automatisk synkroniseringsverktøy som brukes i Microsoft Active Directory miljøer. Den synkroniserer brukerkontoer, grupper og attributter på en planlagt basis (time, daglig eller ukentlig). Den støtter oppsett med flere domener og flere skoger Active Directory og kan synkronisere profilbilder og romobjekter.

Veiviserapp for Entra ID (Azure AD): Denne metoden er designet for organisasjoner som bruker Microsoft Entra ID (Azure AD), og gir automatisk synkronisering i nær sanntid av bruker kontoer og attributter direkte fra Entra ID til. Det er fullt administrert innenfor og krever minimalt oppsett.

SCIM 2.0-applikasjoner: For ikke-Microsoft-miljøer eller andre identitetsleverandører som Okta eller Duo, muliggjør SCIM-baserte synkroniseringsapper automatisk klargjøring og avklaring av brukere med attributttilordning og gruppesynkronisering.

Unified CMbrukersynkronisering: Dette alternativet gjør det mulig å opprette brukerkontoer basert på eksisterende sluttbrukere ved å synkronisere fra til. Dette krever at Cloud Connected UC (CCUC) kjører på lokale klynger. Imidlertid anbefales det generelt å synkronisere brukere fra en sentralisert skykatalog som Entra ID i stedet for direkte fra.

API-klargjøring: Offentlige API-er (People, SCIM 2.0) kan brukes til å klargjøre brukere. Hovedfordelen med å bruke API-er er muligheten til å integrere brukerklargjøring med andre bedriftssystemer.
Tabell 6. Alternativer for klargjøring av brukere for
Klargjøringsmetode Beskrivelse Fordeler Ulemper
Manuell Opprett/administrer brukere individuelt i Enkelt for få brukere; ingen infrastruktur nødvendig Ikke skalerbar; tidkrevende for mange brukere
Bulk (CSV-fil) Importer/oppdater brukere i bulk gjennom CSV i Effektiv for grupper; ingen koding kreves Manuell CSV-forberedelse; mindre dynamisk
Mennesker og SCIM 2.0 API Programmatisk brukeradministrasjon gjennom Webex APIer Fleksibel; støtter automatisering og integrering Krever utvikling og infrastruktur
Katalogsynkronisering Automatisk synkronisering fra AD, Entra ID, SCIM-apper, Unified CM Automatiserer livssyklus; støtter filtrering og kartlegging Oppsettkompleksitet: Noen av alternativene har begrensede funksjoner eller krever infrastruktur
Denne oversikten og tabellen gjenspeiler de viktigste alternativene for klargjøring av brukere, fordelene og begrensningene for å hjelpe deg med å velge den beste tilnærmingen for organisasjonens behov.

Brukergrupper

Brukergruppeadministrasjon i lar administratorer organisere brukere i grupper for effektiv masseadministrasjon av lisenser, innstillinger, og ressurser. Grupper bidrar til å effektivisere administrasjonen ved å bruke policyer, lisenser og innstillingsmaler på flere brukere samtidig, i stedet for å administrere brukere individuelt.

Brukergruppeadministrasjon gir flere fordeler, inkludert:

Forenklet administrasjon: Administrer lisenser, innstillinger og policyer for flere brukere samtidig.

Konsist ens: Bruk ensartede innstillinger og lisenser på tvers av brukere i samme gruppe.

Skalerbarhet: Støtter opptil 250 000 medlemmer per gruppe.

Integrering: Synkroniser grupper fra Microsoft Entra ID (Azure AD) eller Active Directory for automatisert bruker- og gruppeadministrasjon.

Fleksibilitet: Opprett lokale grupper eller synkroniser sikkerhetsgrupper; administrer grupp emedlemskap manuelt eller gjennom CSV-filer.

Ressursfordeling: Kontroller tilgangen til innebygde apper og tjenester basert på gruppemedlemskap.

De viktigste brukstilfellene for brukergrupper ved klargjøring er:

Lisenstil delinger: Tilordne lisenser til grupper for automatisk å levere tjenester som samtaler, møter, meldinger eller hybridtjenester til gruppemedlemmer.

Innstillingsmaler: Bruk samlinger av tjenesteinnstillinger (f.eks. meldinger, møte, samtaler) på grupper for jevn brukeropplevelse.

Massebrukeradministras jon: Legg til eller fjern brukere i bulk gjennom CSV-filer eller katalog synkronisering.

Automatisering og integrering: Bruk API-er eller katalogsynkronisering for automatisert bruker- og gruppens livssyklusadministrasjon.

Tabellen nedenfor oppsummerer de forskjellige alternativene for å administrere brukergrupper og gruppe administrasjon i.
Tabell 7. Alternativer for å administrere grupper og gruppemedlemskap
Alternativet Beskrivelse Fordeler Ulemper

gruppeklarering (grupper) Opprett og administrer grupper direkte i. Legg til/fjern medlemmer manuelt eller via CSV. Full kontroll over gruppemedlemskap
Umiddelbar anvendelse av lisenser og maler
Enkelt å opprette og redigere grupper Manuelle oppdateringer kreves
Fare for feil i manuelle CSV-opplastinger
Ingen automatisk synkronisering med eksterne kataloger

Synkroniserte grupper fra Entra ID (Azure AD) eller Active Directory Synkroniser sikkerhetsgrupper og medlemskap automatisk fra eksterne katalog tjenester. Automatisert synkronisering reduserer manuelt arbeid
Sikrer konsistens med bedriftskatalog
Støtter store organisasjoner
Kan ikke redigere gruppemedlemskap i
Synkroniseringsforsinkelse opptil 12 timer
Nestede grupper krever manuell markering

Grupper og SCIM 2.0 API (grupper) Bruk Grupper eller SCIM 2.0 API for programmatisk gruppe- og medlemsadministrasjon Automatisering og integrering med andre systemer
Skalerbar for store eller komplekse miljøer
Krever utviklingsinnsats
Kompleksitet avhenger av API-bruk

Mens synkroniserte grupper sikrer konsistens og tilbyr ett enkelt administrasjonspunkt, er en hybrid tilnærming som kombinerer synkroniserte grupper og grupper (enten administrert i kontrollhub eller gjennom API-er) mulig. Så for eksempel kan grupper for lisenstildeling være synkroniserte grupper, og et eget sett med grupper kan brukes til å tilordne bruker- og anropsmaler.

Denne omfattende tilnærmingen til administrasjon av brukergrupper gjør det mulig for organisasjoner å administrere brukerlisenser, innstillinger, og policyer effektivt, og sikre konsistente og skalerbare samarbeidsopplevelser.

Anbefalt tilnærming når du migrerer fra til

Den primære datakilden for brukere på er databasen, som inneholder sluttbrukerinformasjon. derimot, er ikke typisk den autoritative kilden for brukeridentitetsadministrasjon og enda viktigere vil bli stengt ved slutten av overgangen og er derfor utelukket som langsiktig autoritativ kilde for identitetsinformasjon.

Cisco anbefaler å bruke en sentralisert skykatalog som Microsoft Entra ID (Azure AD) som den eneste kilden til sannhet for brukeridentiteter. Synkronisering av brukere fra Entra ID for å sikre konsistens, forenkler administrasjonen og støtter funksjoner for enkel pålogging (SSO).

For å sikre at alle brukere på også er til stede i Entra ID, bør organisasjoner kontrollere at brukerkontoene i samsvarer med kontoer i Entra ID. Dette kan gjøres ved å eksportere brukerlister fra og sammenligne dem med Entra ID-brukerlister.

Oppsummert er den anbefalte klargjøringsmetoden å synkronisere brukere fra Microsoft Entra ID (Azure AD) til Webex ved hjelp av Azure AD-veiviseren eller SCIM-appene. Manuell og CSV-masseklargjøring er tilgjengelig som tilleggsmetoder, men er mindre skalerbar og mer utsatt for feil for store organisasjoner. Å sikre at Entra ID er den autoritative kilden og at alle brukere eksisterer i Entra ID er avgjørende for en vellykket migrering og konsekvent bruker opplevelse på tvers av miljøer.

Overgang fra en lokal katalogtjeneste, for eksempelActive Directory, til en skykatalogtjeneste, som Entra ID (Azure ID), er uavhengig av anropsovergangen. Cisco anbefaler å fullføre over gangen til en skykatalogtjeneste før du starter anrops overgangen.

Utforming av brukergrupper

Etter overgang av bedriftskatalogen fra lokal til skyen samler du de nødvendige brukergruppene drevet av lisensierings- og funksjonsmalkrav . For hvert gruppedokument:

Gruppenavn: unikt navn på gruppen.

Lisenser: lisenser som skal tilordnes denne gruppen (hvis noen) og omfang (bør lisenser tilordnes eksisterende brukere eller bare til nye brukere)

Innstillingsmaler: Webex App- og Brukersamtalemaler.

Katalogsynkronisering: Vil denne gruppen synkroniseres fra bedriftskatalogen, eller er dette en lokal Webex-gruppe klargjort i Control Hub eller gjennom en API.

Beskrivelse: hvordan vil denne gruppen bli brukt og hvilke brukere som skal være medlemmer av denne gruppen

Disse detaljene vil bli brukt senere i implementeringsfasen for å opprette lokale grupper eller grupper i bedriftskatalogen og administrere gruppemedlemskap for brukere.

Enkel pålogging (SSO)

Cisco anbefaler bruk av SSO for brukerautentisering. Å bruke SSO har noen overbevisende fordeler, inkludert:

Forenklet brukerautentisering: Brukere kan logge på én gang ved å bruke bedrift slegitimasjonen (f.eks. fra Azure ID) for å få tilgang til og andre integrerte applikasjoner, noe som eliminerer behovet for flere passord og reduserer påloggingsforespørsler. Dette forbedrer sikkerheten ved å sikre at bedriftspassord aldri lagres eller overføres til etter godkjenning.

Forenklet brukeradministrasjon: Automatiserer oppretting, oppdateringer og deaktivering av brukerkontoer basert på endringer i bedriftskatalogen, reduserer administrative kostnader og sikrer at bare autoriserte brukere har tilgang.

Forbedret sikkerhet: SSO reduserer passordutmattelse og risikoen for passordrelaterte brudd ved å sentralisere autentisering gjennom pålitelige identitetsleverandører (IDP).

Enkel integrering av multifaktorautentisering (MFA): MFA kan enkelt støttes enten gjennom en Identity Access Management- løsning som Cisco Duo eller gjennom MF A-støtte for IdP.

Det er flere alternativer for å implementere SSO for tjenester:

SAML 2.0-basert SSO: Den primære protokollen som støttes for S SO-integrasjon, muliggjør sikker utveksling av autentiseringsinformasjon mellom Id P og tjenesteleverandøren.

OpenID connect (OIDC): Støttes som en alternativ moderne autentiseringsprotokoll for SSO-integrasjon.

Webex-identitet: Støttes også som et alternativ for identitetsleverandør.

SSO konfigureres og administreres sentralt gjennom, noe som krever metadatautveksling mellom og den valgte IdP.

Etter konfigurasjon kan SSO testes innen før aktivering for å sikre riktig oppsett.

Cisco støtter integrasjon med flere testede og ofte brukte IDP-er og Identity Management Systems (IAM), inkludert, men ikke begrenset til:

Cisco Duo

Okta

Microsoft Active DirectoryFøderasjonstjenester (ADFS)

Microsoft Azure

Ping Federate

OpenAM

F5 BIG-IP.

Disse IDP-ene samsvarer med SAML 2.0- eller OpenID Connect-standarder og er validert for kompatibilitet med Ciscos samarbeidsløsninger.

Støtte for flere IdP

lar organisasjoner konfigurere SSO med flere IDP-er for å imøtekomme komplekse IT- miljøer som fusjoner, oppkjøp eller desentraliserte IT-avdelinger der forskjellige grupper bruker forskjellige IDP-er. Støtte for flere IdP kan enten implementeres ved hjelp av Multi ple IdP-funksjonen i eller gjennom integrering av et bedrifts IAM-system som Cisco Duo.

Støtte for flere identitetsleverandører (IdP) adresserer flere viktige brukstilfeller der organisasjoner krever fleksibel og sikker autentisering på tvers av ulike IT-miljøer:

1. Fusjoner og oppkjøp

Når selskaper fusjonerer eller kjøper andre, har de ofte separate IT-infrastrukturer og distinkte IDP-er som ikke kan føderere seg. Støtte for flere IdP gjør det mulig for brukere fra begge organisasjoner å autentisere og samarbeide sikkert uten å måtte forene identitetssystemene sine umiddelbart.

2. Flere uavhengige IT-avdelinger

Store organisasjoner eller offentlige institusjoner kan ha flere uavhengige IT-avdelinger, som hver administrerer sin egen IdP. Den flere IdP-funksjonen gjør det mulig for disse avdelingene å opprettholde sine egne autentiserings systemer samtidig som brukerne får tilgang sømløst.

3. Ulike brukergrupper eller domener

Organisasjoner med ulike brukergrupper (f.eks. ansatte kontra entreprenører) eller flere e-post domener kan konfigurere rutingsregler for å dirigere godkjenningsforespørsler til riktig IdP basert på domene- eller gruppemedlemskap. Dette støtter differensierte tilgangspolicyer og sikkerhet skontroller.

4. Støtte for ulike autentiseringsprotokoller

støtter SAML- og OpenID Connect (OIDC) IDP-er, slik at organisasjoner kan integrere forskjellige typer identitetsleverandører i henhold til deres eksisterende infrastruktur og sikkerhetskrav.

5. Forbedret sikkerhet og samsvar

Ved å aktivere flere IDP-er kan organisasjoner implementere sterkere autentiseringsmekanismer, inkludert multifaktorautentisering (MFA) gjennom integrasjoner som Duo, og håndheve konsistente sikkerhetspolicyer på tvers av ulike brukerbaser.

6. Forenklet brukeropplevelse

Brukere kan autentisere ved hjelp av eksisterende legitimasjon fra sine respektive IDP-er, noe som gir en enhetlig påloggingsopplevelse til tross for den underliggende kompleksiteten til flere identitetssystemer.

Selv om flere IdP-støtte gir fleksibilitet, krever det nøye koordinering mellom sikkerhets- og identitetsteam for å opprettholde konsistente sikkerhetspolicyer og unngå potensielle sårbarheter.

Duo MFA med SSO for

Duo Access Gateway (DAG) kan autentisere brukere ved hjelp av eksisterende lokale eller skybaserte kataloger som Active Directory (AD) og OpenLDAP. Den støtter også integrasjon med andre identitetsleverandører som Microsoft ADFS, Microsoft Azure, Okta, OneLogin, CAS og Shibboleth. Denne fleksibiliteten gjør det mulig for organisasjoner å bruke sin nåværende katalog infrastruktur for Webex SSO med Duo MFA.

Duo fungerer som et sterkt autentiseringslag på toppen av den primære katalogautentiseringen. Den fungerer som en identitetsleverandør (IdP) ved hjelp av SAML 2.0 for å håndheve tofaktorautentisering (2FA) før du gir tilgang til. Duo evaluerer bruker-, enhets- og nettverkskontekst mot konfigurerbare retningslinjer for å tillate eller nekte tilgang, noe som forbedrer sikkerheten utover bare brukernavn og passord. Duo gir også fleksible policykontroller, for eksempel å kreve MFA ved hver pålogging for noen apper og sjeldnere for andre.

Fordelene med Cisco Duo inkluderer:

Forbedret sikkerhet: Leg ger til phishing-resistent MFA for å beskytte tilgang, og reduserer risikoen fra kompromitterte passord.

Fleksible policyer: Tillater detaljert kontroll over godkjenningskrav per applikasjon eller brukergruppe.

Integrasjon med eksisterende kataloger: Stø tter lokal AD, OpenLDAP, sky kataloger og ulike SSO-leverandører, noe som minimerer endringer i infrastruktur.

Brukervennlighet: Stø tter enkel pålogging (SSO) for å redusere passordutmattelse ved å gjøre det mulig for brukere å logge på én gang og få tilgang til flere ressurser på en sikker måte.

Klarerte endepunkter: Stø tter enhetstillit for klienter på Windows og macOS, noe som forbedrer sikkerhetsstillingen.

Selvbetjeningsregistrering: Inline-påmelding og duo-prompt forbedrer brukeropplevelsen under MFA-oppsett.

Duo MFA med SSO for utnytter eksisterende kataloger som Active Directory og OpenLDAP, eller skyidentitet sleverandører, for å autentisere brukere. Duos rolle er å tilby en sterk, policydrevet andre autentiserings faktor integrert gjennom SAML 2.0, noe som forbedrer sikkerheten samtidig som brukervennligheten opprettholdes gjennom SSO. Fordelene inkluderer forbedret sikkerhetsstilling, fleksibel håndheving av policyer, sømløs integrasjon og en bedre brukeropplevelse.

Cisco anbefaler å implementere SSO for brukere. For forbedret sikkerhet anbefales integrasjon med Cisco Duo.

Enterprise IAM- og SSO-strategien bør implementeres før overgangen fra til starter.

Funksjoner

har et komplett utvalg av kjernefunksjoner som følger med tjenesten. Dette inkluderer mange anropsfunksjoner i bedriftsklasse som har vært tilgjengelige i mange år. Du ser kanskje ikke 100% paritet mellom funksjoner og funksjoner, men som du kan se i figuren nedenfor, er de viktigste anropsfunksjonene tilgjengelige i.

Webex Callingfunksjoner i bedriftsklassen

Foruten de mange brukerfunksjonene, har kjernesystemfunksjoner som følger med plattformen. Disse inkluderer funksjoner som autovertakere, samtalekøer, anropspark, etc. Du kan se alle tilgjengelige kjernesystem funksjoner under Service → Anrop → Funksjoner som vist i figur Webex Callingkjerne funksjoner.

Webex Callingkjernefunksjoner

Automatisk ledsager

Auto Attendant muliggjør 24/7 automatisering av håndtering av innkommende anrop, noe som muliggjør effektiv samtalehåndtering uten at en person trenger å svare på hvert anrop.

Den automatiske svartjenesten svarer på innkommende anrop og gir den som ringer en meny med alternativer for hvor de vil dirigere samtalen. Dette kan være til en person, en telefonsvarerboks eller en anropstjeneste (f.eks. Anropskø). Den som ringer bruker telefonens nummertastatur for å skrive inn nummeret fra den automatiske svar menyen.

Auto Attendant støtter følgende viktige funksjoner:

Forretnings- og ettertidsplaner

Ferieplan

Alternativet for oppringingsmeny for å lede kundene dine dit de trenger å gå

Tilpass hilsener

Alternativ for å ringe etter navn

Alternativer for viderekobling av anrop

Control Hub-analyser og rapporter.

Hvis du vil ha mer informasjon, kan du se Administrer automatiske svartjenester.

Ring Park

Call park gir brukerne muligheten til enkelt å sette et anrop på vent slik at en annen bruker enkelt kan hente når de er tilgjengelige for å ta det. Det frigjør også brukeren som svarte på det opprinnelige anropet for å ringe eller motta andre samtaler mens samtalen er parkert.

Det er to typer anropsparker tilgjengelig i:

Call park direct - gjør det mulig for enhver bruker å parkere et anrop til en annen brukers utvidelse eller til en samtaleparksutvidelse, som definert av administratoren

Anropsparkgruppe - lar en definert gruppe brukere automatisk parkere anrop mot tilgjengelige parkdestinasjoner definert for gruppen. Disse destinasjonene kan være gruppemedlemmenes utvidelser eller anropsparkutvidelser.

Basert på konfigurasjon og parkeringstype kan brukere hente anrop ved å ringe *88+><extension of parked call>, trykke på linjetasten som er knyttet til anropsparkutvidelsen eller bruke en funksjonstast på IP-telefonen.

Et tilbakekallingsalternativ er tilgjengelig for å tilbakekalle et parkert anrop etter en spesifisert periode til brukeren som parkerte samtalen eller til en alternativ bruker.

Hvis du vil ha mer informasjon, kan du se Administrer anropsparkering i Control Hub.

Henting av anrop

Henting av anrop gjør det mulig for en administrator å definere en gruppe brukere (medlemmer) som kan svare på et an rop til et annet medlems telefon. Dette gir en bruker muligheten til å svare på anrop når lagkameratene er opptatt og ikke kan svare på et innkommende anrop.

Brukerne i en gruppe må være på samme sted.

Brukere kan bruke enten skrivebordstelefonen eller skrivebordstelefonen til å hente en samtale.

:

Støtter visuelle og lydvarsler

Varsling om innkommende anrop

FAC-basert (ring *98) eller varslingsopptak

Varsler om henting av anrop for multilinje.

Skrivebordstelefoner:

Varsling om innkommende anrop

Lydklokkespill og visuell varsling gjennom håndsettets LED. 6821 støtter bare lydklokker

Når varslingstypen er valgt i er ikke ingen

Varsler om henting av anrop bare for primære linjer.

Hvis du vil ha mer informasjon, kan du se Konfigurere samtaleopptak sgruppe.

Anropskø

inkluderer kun taleanropskøer som en del av kjernefunksjonene, og enhver bruker med en Professional-lisens kan være en del av en anropskø, agent eller veileder. Denne funksjonen lar brukerne effektivt engasjere seg med kunder. Samtalekøer støtter et delsett av noen av kjernefunksjonene i kundes enteret som talekøer, tilbakeringing, ferdighets- eller prioritetsruting, agentkø styring, analyse, rapportering, etc.

Ciscos oppfordring til Microsoft Teams-integrasjon gir agenter tilgang til anropskøanrop og funksjoner direkte fra Microsoft Teams-klienten.

Anropskøer støtter følgende viktige funksjoner:

Hilsener og meldinger (velkommen, komfort, hvisking osv.)

Hold musikk

Tilbakeringing

Retningslinjer for køruting (natttjeneste, helligdager, videresending)

Pålogging/utlogging av agentkø

Administrasjon av agentkøstatus

eller skrivebordstelefonstøtte

Veilederagent ringer overvåking, trener, lekter eller overtar gjennom Feature Access Codes (FACs)

(administratortilgang) for:

køadministrasjon

Agent- og køanalyse og rapportering

Kø-, agent- og veilederledelse.

Hvis du vil ha mer informasjon, kan du se Konfigurere anropskø.

har en tilleggsfunksjon for kundeassistanse som gir ekstra anropskøfunksjoner og gir agenter og veiledere en bedre brukeropplevelse innen. Hvis du vil ha en sammenligning av funksjonene Anropskø og Kundeservice, kan du se Sammenligning av funksjoner for an Webex Calling ropsk ø og kundestøtte.

Jaktgruppe

Jaktgrupper tillater ruting av innkommende anrop til en bestemt gruppe brukere gjennom et forhåndsbestemt samtalerutingsmønster. Dette sikrer at samtaler besvares av riktig gruppe brukere eller sendes til en telefonsvarer for oppfølging.

En stor forskjell mellom Hunt Groups og Call Queues er at samtaler ikke står i kø i en Hunt Gro ups, så hvis ingen brukere i Hunt Group er tilgjengelige for å svare på samtalen, vil den bli koblet fra, sendt til telefonsvarer eller videresendt til et annet nummer (bruker eller tjeneste).

Hvis du vil ha mer informasjon, kan du se Administrer jaktgrupper i Control Hub.

Driftsmoduser

Funksjonen Operating Modes lar bedrifter effektivt rute samtaler til forskjellige destinasjoner (brukere, telefonsvarer, ringetjenester som en anropskø). Hvor og når et anrop rutes er basert på en tids plan for tid på dagen og ukedag, og enhver bruker kan autoriseres til å administrere disse modusene (tidsplanene) for å kontrollere endringer i samtalerutingen.

For eksempel kan anrop til en anropskø rutes til en annen anropskø med agenter i en annen tidssone for å svare på anrop etter arbeidstid, i arbeidstid rutes til lokale agenter, og i løpet av helligdager rutes til telefonsvarer for opp følging etter at agenter kommer tilbake til kontoret.

En autorisert bruker kan bytte mellom disse forskjellige viderekoblingsscenariene (modusene) hvis de trenger å endre hvor innkommende anrop rutes i en viss periode. Disse brukerne kan administrere modus ene gjennom 6800/7800/8800 MPP-telefoner, 9800-telefoner eller i brukernavet i Administrer moduser.

Hvis du vil ha mer informasjon, kan du se Anropsruting basert på driftsmoduser i Webex Calling.

Personsøkingsgruppe

Personsøkingsgrupper lar brukerne ringe en enveis samtale for å sende en lydmelding til en gruppe brukere. Hver gruppe kan inneholde opptil 75 målbrukere og/eller arbeidsområder som nås ved å ringe et forhånds definert nummer eller en utvidelse.

Når en bruker kaller en personsøkingsgruppe, blir det foretatt et samtidig anrop til alle de tildelte målene i gruppen, på hvilket tidspunkt den som ringer kan snakke meldingene sine og legge på når de er ferdige.

Hvis du vil ha mer informasjon, kan du se Konfigurere en personsøkingsgruppe i Control Hub.

Innspillinger

støtter opptak av samtaler foretatt eller mottatt av en bruker. Dette kan være nødvendig for kvalitet, sikring, sikkerhet eller opplæringsbehov. Som standard blir samtaler spilt inn, men andre tredjeparts opptaksleverandører kan også brukes hvis andre opptaks funksjoner eller samsvar og forskriftskrav er påkrevd.

Når du bruker som opptaksplattform, administreres alle innspilte samtaler innenfor. Fullstendige administratorer med rollen som Compliance Officer kan spille og laste ned opptakene. Uten rollen som Compliance Officer kan administratoren bare slette opptakene.

Hvis du vil ha mer informasjon om denne funksjonen og en liste over tredjepartsopptak, kan du se Administrer anrops opptak for Webex Calling.

Enkeltnummerrekkevidde

Enkeltnummerrekkevidde gjør det mulig å ringe til en brukers telefonnummer for å ringe flere enheter. Dette kan omfatte andre skrivebordstelefoner så vel som mobiltelefoner. Samtaler kan også plasseres fra disse enhetene, og brukere kan skyve og trekke samtaler mellom dem.

Hvis du vil ha mer informasjon om denne funksjonen og hvordan en administrator konfigurerer den, kan du se Konfigurere enkeltnummerrekkevidde (kontor hvor som helst).

Hvis du vil ha mer informasjon om hvordan en bruker kan administrere og konfigurere denne funksjonen for seg selv i Webex User Hub (portalen), kan du se Konfigurere enkeltnummerrekke vidde (kontor hvor som helst).

Talepostgruppe

Talepostgrupper tillater en delt talepostboks som kan tilordnes en bruker- eller samtalerutingsfunksjon. Noen av grunnene til at en talepostgruppe kan være nødvendig er:

Generell telefonsvarer for en avdeling eller arbeidsgruppe

Legg til talepostalternativ til en automatisk svartjeneste eller jaktgruppe

Slik sender du overløpsanrop fra en anropskø

Brukere som bare trenger en talepostboks.

Hvis du vil ha mer informasjon, kan du se Administrer en delt talepost og innkommende faksboks for. Webex Calling

Attendant Console er oppført på siden Anropsfunksjoner i Webex, men det er en tilleggsfunksjon som krever kjøp av den medfølgende konsoll lisensen for å bruke.

Hvis du vil ha mer informasjon, kan du se Komme i gang med Attendant Console.

Hvis du vil ha informasjon om alle funksjoner, inkludert noen tilleggsfunksjoner, kan du se Funksjoner tilgjengelig etter lisenstype for Webex Calling.

Tabell 1. Informasjon som skal innhentes for hvert sted
Informasjon	Kommentar
Utvidelsesområde (er)	Hvert sted i kan ha utvidelser som starter med forskjellige sifre. Ett siffer må spares for styr ingssifferet mellom lokalene (for eksempel 8) og ett for PSTN- styresifferet (for eksempel 9). Ingen utvidelsesområde kan starte med noen av disse to sifrene. Alle utvidelsesområder på alle steder må være like lange.
DID-område (er)	-
PSTN styringssiffer	-
Nettstedskode	Alle nettstedskoder for alle steder må være unike og ha samme lengde.
Hovednummer	Når du oppretter et sted, må to DID-er klargjøres. Ett som hovednummer (for eksempel for å tilordnes en automatisk svartjeneste) og ett for telefonsvar erportalen. Bestem en DID for telefonsvarernummeret.
Talepostnummer
Antall lisenser	Nødvendige lisenser etter type inkludert Standard, Professional, Workspace, Ruteliste, Utgående anropsplan.
Samtidige samtaler i den travle timen	Summen av samtidige samtaler mellom enheter og mellom enheter og den lokale gatewayen (PSTN og anrop til enheter). Nødvendig for å bestemme den nødvendige båndbredden til internettilgang.
Land	-
Tidssone	-
Språk	-
Kontakt (Navn, Telefon, E-post)	-
Adresse (Gateadresse, by, stat, postnummer)	-
Nødetjenestens fysiske utsendelsessted for endepunkter	Enhetsforsendelsessted som brukes til nødanrop inkluderer vanligvis følgende: bygningsadresse, bygningsadresse + etasjenummer, bygningsadresse+ suitenummer eller bygningsadresse + etasjenummer+kontor/kubisk nummer.
Per enhet unik fysisk nettverksplassering for nødetjenester	Fysisk nettverksplassering for nødanrop inkluderer vanligvis følgende: svitsj/bryterport for kablede enheter, BSSID-er (Basic Service Set Identifiers) for trådløst tilkoblede enheter og/eller lokale IP-delnett (er) for endepunktsenheter.

Tabell 2. Eksempel på bedriftsnummerering
Nettstedet	Utvidelsesområde	Nettstedskode	Enterprise-utvalg
NYC	2XXX	202	8 202 2XXX
SFO	3XXX	203	8 203 3XXX
RTP	2XXX	204	8 204 2XXX

Tabell 3. Faste lengdeforlengelsesområder
Nettstedet	Utvidelsesområde	Utvidelser	Nettstedskode	Enterprise-utvalg
NYC	2XXX	2XXX	202	8 202 2XXX
SFO	8XXX	7XXX	203	8 203 7XXX
RTP	1XX	11XX	204	8 204 11XX

Tabell 4. Overgang av syv-sifret oppringing

Nettstedet	Utvidelser	Nettstedskode	Enterprise-utvalg	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

Tabell 5. Brukerklargjøringsalternativer - sammendrag
Oppgavemetode	Fordeler	Ulemper
Manuell gjennom	Enkelt for få brukere. Tillater presis og detaljert kontroll over lisenstildeling.	Ikke skalerbar, tidkrevende Utsatt for menneskelige feil under manuell oppføring.
Automatiske lisensmaler	Skalerbar Reduserer manuelle feil Kan brukes på nye og eksisterende brukere.	Krever gyldige telefonnumre og steder. Mer komplisert å sette opp Krever også brukergrupper per gruppe brukere med tilsvarende lisensieringskrav.
Masseopplasting av CSV	Effektiv for store brukersett Tillater samtidig tildeling av lisenser, telefonnumre og utvidelser.	Krever nøye CSV-formatering Potensial for feil hvis telefon numre eller utvidelser mangler eller er feil.
API-basert oppgave	Automatiserbar, fleksibel. Tillater samtidig tildeling av lisenser, telefonnumre og utvidelser.	Krever utvikling og API-kunnskap.

Tabell 6. Alternativer for klargjøring av brukere for
Klargjøringsmetode	Beskrivelse	Fordeler	Ulemper
Manuell	Opprett/administrer brukere individuelt i	Enkelt for få brukere; ingen infrastruktur nødvendig	Ikke skalerbar; tidkrevende for mange brukere
Bulk (CSV-fil)	Importer/oppdater brukere i bulk gjennom CSV i	Effektiv for grupper; ingen koding kreves	Manuell CSV-forberedelse; mindre dynamisk
Mennesker og SCIM 2.0 API	Programmatisk brukeradministrasjon gjennom Webex APIer	Fleksibel; støtter automatisering og integrering	Krever utvikling og infrastruktur
Katalogsynkronisering	Automatisk synkronisering fra AD, Entra ID, SCIM-apper, Unified CM	Automatiserer livssyklus; støtter filtrering og kartlegging	Oppsettkompleksitet: Noen av alternativene har begrensede funksjoner eller krever infrastruktur

Tabell 7. Alternativer for å administrere grupper og gruppemedlemskap
Alternativet	Beskrivelse	Fordeler	Ulemper
gruppeklarering (grupper)	Opprett og administrer grupper direkte i. Legg til/fjern medlemmer manuelt eller via CSV.	Full kontroll over gruppemedlemskap Umiddelbar anvendelse av lisenser og maler Enkelt å opprette og redigere grupper	Manuelle oppdateringer kreves Fare for feil i manuelle CSV-opplastinger Ingen automatisk synkronisering med eksterne kataloger
Synkroniserte grupper fra Entra ID (Azure AD) eller Active Directory	Synkroniser sikkerhetsgrupper og medlemskap automatisk fra eksterne katalog tjenester.	Automatisert synkronisering reduserer manuelt arbeid Sikrer konsistens med bedriftskatalog Støtter store organisasjoner	Kan ikke redigere gruppemedlemskap i Synkroniseringsforsinkelse opptil 12 timer Nestede grupper krever manuell markering
Grupper og SCIM 2.0 API (grupper)	Bruk Grupper eller SCIM 2.0 API for programmatisk gruppe- og medlemsadministrasjon	Automatisering og integrering med andre systemer Skalerbar for store eller komplekse miljøer	Krever utviklingsinnsats Kompleksitet avhenger av API-bruk

Implementere

Nettverksberedskap

Innledende oppsett

Domenebekreftelse

Gjør krav på (konverter) eksisterende brukere

Konfigurer og test katalogsynkronisering

Konfigurere og teste Single Sign-On (SSO)

Anskaffe, levere og verifisere lisenser

Webex Callingtjenesteinnstillinger

Pilotmigrasjon

Anskaffe PSTN

Konfigurer lokasjoner

Integrasjon med lokal samtalekontroll

Overfør brukere i grupper

Arbeidsområder

Tilveiebringsenheter

Konfigurer funksjoner

Godkjenningstesting

Nettverksberedskap

Det første trinnet i overgangen til er å sikre pålitelig og sikker Internett-tilkobling mellom det lokale nettverket og skyen.

Siden de fleste organisasjoner kobler seg til internett via en eller flere brannmurer eller sikkerhetsenheter, er det viktig å validere at de nødvendige trafikkstrømmene støttes.

Nettverks- og sikkerhetsadministratorer må forstå disse flytene i form av:

Retning (innkommende vs utgående)

Protokoller (Eksempel - SIP TLS, SRTP, HTTPS)

IP-adresseområder som brukes av tjenester

Portnumre som må åpnes eller tillates.

Dette sikrer at bedriftens brannmurer, NAT-enheter og annen nettverksinfrastruktur er riktig konfigurert for å imøtekomme trafikk samtidig som bedriftens sikkerhetspolicyer opprettholdes.

For informasjon om nødvendige flyter, inkludert IP-adresse, porter, og protokoller, se Portreferanseinformasjon for Webex Calling. Bruk denne informasjonen til å konfigurere brannmuren, proxyer og annen nettverksinfrastruktur i den eksisterende distribusjonen for å aktivere nettverksflyter.

Desentralisert internettutbrudd fra hver filial eller nettsted er den anbefalte tilnærmingen for skysamarbeidstjenester som. Ved å la trafikken gå ut lokalt, gjør denne modellen følgende:

Reduserer tur-returforsinkelse og jitter, og forbedrer den generelle samtalekvaliteten

Skalerer effektivt etter hvert som flere brukere og nettsteder går over til

Fungerer sømløst med SD-WAN, som dynamisk kan rute økter til nærmeste skyinngangspunkt for optimal ytelse

Tillater å spore brukerplassering basert på deres offentlige IP-adresse, noe som hjelper med mediebane analyse og feilsøking.

I tillegg må organisasjoner sørge for tilstrekkelig internettbåndbredde på hvert nettsted. Bå ndbredde bør dimensjoneres basert på forventet antall samtidige anrop, den valgte kodeken (f.eks. Opus eller G.711), pluss overhead for signalering, retransmisjoner og vekst. Dette stemmer overens med forberedelsesfasen i PPDIO-livssyklusen og etablerer et solid fundament for migrering.

Innledende oppsett

Den første oppsettdelen i implementeringsfasen av distribusjonen er grunnleggende for å etablere et godt strukturert og håndterbart skyanropsmiljø. Dette stadiet omfatter kritiske oppgaver som å sette opp organisasjonen, anskaffe og tildele lisenser, og verifisere og gjøre krav på bedriftens domener for å sikre riktig brukeradministrasjon og sikkerhet. I tillegg inkluderer den klargjørings lisensmaler for å automatisere tildelinger av brukerlisenser, konfigurere Single Sign-On (SSO) for å effektivisere brukerautentisering og forbedre sikkerheten, og justere tjeneste- og klientinnstillinger slik at de stemmer overens med organisasjonspolicyer og brukerbehov. Å fullføre disse innledende konfigur asjonsaktivitetene sikrer at miljøet er riktig konfigurert for skalerbarhet, sikkerhet og sømløs brukeropplevelse, og setter scenen for påfølgende distribusjons- og driftsfaser.

Domenebekreftelse

For å kunne identifisere brukere som er registrert med bedriftens e-postdomener på, er det viktig å bekrefte domenene dine. Uten domenebekreftelse vil brukere bli tildelt en forbrukerorganisasjon, noe som kompliserer brukeradministrasjonen for bedriften din. Domenebekreftelse er et obligatorisk trinn som gjør at organisasjonen din kan kreve og administrere disse brukerne effektivt.

Sørg for at alle domener som er knyttet til brukernes e-postadresser er bekreftet. Domene bekreftelse er ikke eksklusiv; det samme domenet kan verifiseres på tvers av flere organisasjoner.

Hvis du vil ha mer informasjon om hvordan du administrerer domener, kan du se Administrer domenene dine.

Gjør krav på (konverter) eksisterende brukere

Etter at du har bekreftet domenene dine, kan du fortsette å gjøre krav på brukere som har registrert seg for å bruke bedriftens e-postdomener i organisasjonen. Denne prosessen konsoliderer alle brukere under en enkelt organisatorisk paraply, noe som muliggjør sentralisert administrasjon og strømlinjeformet administrasjon. Ved å gjøre krav på disse brukerne sikrer du at bedriften din har full kontroll over brukerkontoer, slik at du kan tilordne passende lisenser, konfigurere tjenester og gi nødvendig støtte effektivt. Denne enhetlige administrasjonsmetoden forbedrer sikkerheten, forenkler klargjøring av brukere og sikrer jevn tilgang til tjenester i hele organisasjonen. Å hevde brukere forhindrer dem også i å bli administrert i eksterne organisasjoner eller forbrukerorganisasjoner, og opprettholder dermed organisasjonsintegritet og kontroll over samarbeidsressurser.

Hvis du vil ha mer informasjon om hvordan du gjør krav på brukere, kan du se Gjør krav på brukere av organisasjonen (konverter).

Konfigurer og test katalogsynkronisering

Hvis du vil aktivere sømløs bruker- og gruppeadministrasjon, kan du synkronisere brukere og grupper fra bedriftskatalogen enten Microsoft Entra ID (tidligere Azure AD) eller Microsoft Active Directory (AD) til. Denne prosessen sikrer at brukeridentiteter og gruppemedlemskap opprettholdes konsekvent på tvers av miljøet ditt.

For organisasjoner som implementerer trinnvise distribusjoner, er det avgjørende å kontrollere og begrense omfanget av synkronisering under første utrulling. Dette minimerer risikoen for utilsiktede endringer og gir mulighet for målrettet testing før bredere adopsjon.

Den mest effektive metoden for å filtrere hvilke brukere som synkroniseres, er å utnytte kataloggruppemedlemskap:

1
Opprett en dedikert synkroniseringsgruppe: I bedriftskatalogen (Microsoft Entra ID eller AD) oppretter du en sikkerhetsgruppe spesielt for synkronisering (for eksempel synkroniseringsgruppe).

2
Fyll gruppen med målbrukere: Legg bare til brukerne du vil synkronisere (for eksempel en testgruppe under pilotfasen) i denne gruppen. Dette lar deg kontrollere hvem som er inkludert i synkroniseringsprosessen tett.

3
Konfigurer synkroniseringsavtalen med gruppebasert filtrering: Når du konfigurerer synkroniseringsavtalen i Directory Connector eller Entra ID-klargjøring, konfigurerer du omfanget slik at det bare inkluderer brukere som er medlemmer av den angitte gruppen.

For Microsoft Entra ID kan du bruke gruppebaserte tildelinger i klargjøringsinnstillingene

For AD kan du definere et LDAP-filter som bare inkluderer brukere som tilhører den angitte gruppen.

4
Utvid gruppen etter behov: Når du går videre til bredere distribusjonsfaser, legger du bare til flere brukere eller grupper i synkroniseringsgruppen. Synkroniseringsomfanget utvides automatisk til å omfatte disse brukerne, noe som muliggjør kontrollert og gradvis utrulling.

Eksempel på implementeringstrinn:

I aktiv katalog:

Opprett en sikkerhetsgruppe med navnet synkroniseringsgruppe.

Legg til ønskede pilotbrukere i denne gruppen.

Sett opp Directory Connector med et LDAP-filter som: (MemberOF=CN=WebEx Sync Group, OU = Groups, DC=Ditt domene, DC=COM).

I Microsoft skriver du inn ID:

Opprette en gruppe med navnet synkroniseringsgruppe

Tilordne gruppen til klargjøringsinnstillingene i Entra ID

Bare brukere i denne gruppen vil bli klargjort til.

Test alltid gruppebasert synkronisering i et ikke-produksjonsmiljø før du søker på hele organisasjonen

Gjennomgå gruppemedlemskap regelmessig for å sikre at bare autoriserte brukere synkroniseres

For løpende administrasjon kan du automatisere oppdateringer av gruppemedlemskap basert på forretnings regler eller HR-systemer hvis mulig.

Referanser:

Synkroniser Entra ID-brukere til Control Hub

Konfigurere veiviserappen Entra ID i Control Hub

Katalogkontakt

Konfigurere og teste Single Sign-On (SSO)

Single Sign-On (SSO) forbedrer sikkerheten og forenkler brukertilgangen ved å la brukerne autentisere én gang med bedriftens legitimasjon og få sømløs tilgang til. støtter SSO-integrasjon med SAML 2.0-kompatible IDP-er, inkludert Microsoft Entra ID (tidligere Azure AD), Active Directory (AD) fødererte løsninger og ulike tredjeparts IDP-er.

På dette tidspunktet bør det designede SSO-oppsettet implementeres og testes.

Referanser:

Enkel påloggingsintegrasjon i kontrollhuben

konfigurere enkel pålogging for webex-administrasjon

Konfigurer enkel pålogging med Microsoft Entra ID

SSO med flere IDP-er

Administrer SSO ved integrering i Control Hub

Anskaffe, levere og verifisere lisenser

Som en del av det første oppsettet for, er det viktig å skaffe, klargjøre og verifisere de riktige lisensene for å aktivere og administrere tjenester effektivt. Innkjøpsprosessen innebærer å velge lis enstyper basert på brukerroller og arbeidsbelastninger, for eksempel Professional-, Standard- og Workspace- lisenser. Lisenser genereres og leveres gjennom Ciscos programvareplattformer eller gjennom partnere. Etter anskaffelse og klargjøring må riktige lisenstall verifiseres i. Denne prosessen sikrer at organisasjonen har de riktige lisensene aktivert og klar til bruk i distribusjonen.

Som en del av det første lisensieringsoppsettet i, er det viktig å konfigurere organisasjonsbasert automatisk lisensiering for å effektivisere lisenstildeling for nye brukere. Dette oppsettet gjør det mulig å gi lisenser automatisk når brukere legges til i organisasjonen, noe som eliminerer behovet for manuell lisenstil deling. Når du konfigurerer automatisk lisensiering på organisasjonsnivå, velger du tjenestene som skal tilordnes og definerer omfanget, for eksempel å bruke lisenser bare på fremtidige brukere eller inkludere eksisterende brukere også.

Hvis distribusjonsplanen innebærer bruk av automatisk lisensiering på gruppenivå i stedet, kan du imidlertid velge å ikke tilordne lisenser på organisasjonsnivå for å unngå konflikter eller dupliserte lisenstildelinger. Med automatisk lisensiering på gruppenivå tildeles lisenser basert på gruppemedlemskap. Brukere i flere grupper mottar lisenser fra alle gjeldende gruppetildelinger.

Gruppebasert lisenstildelingskonfigurasjon må utføres etter at katalogsynkroniseringen er fullført, slik at synkroniserte grupper eksisterer og kan brukes til lisenstildeling.

Spesielt krever automatisk lisenstildeling ytterligere klargjøringsdetaljer, for eksempel brukerplassering og tildeling av telefonnummer. Brukerens arbeidstelefonnummer må være i +E.164-format, forhåndsbestemt og tilordnet et gyldig sted for at lisensen skal aktiveres automatisk. Hvis disse betingelsene ikke er oppfylt, vil brukeren ikke få tjenester automatisk, og det kan kreve manuell inngrep.

Oppsummert kan du konfigurere organisasjonsbasert automatisk lisensiering for nye brukere hvis du vil ha en bred lisenstilordning for hele organisasjonen. Hvis du foretrekker mer detaljert kontroll eller har forskjellige lisensieringsbehov per gruppe, kan du konfigurere automatisk lisensiering på gruppenivå og unngå å tilordne lisenser på organisasjonsnivå for å forhindre overlapping og sikre riktig lisensadministrasjon.

Webex Callingtjenesteinnstillinger

Det er viktig å gjennomføre en omfattende gjennomgang og konfigurasjon av de globale tjeneste innstillingene innenfor.

Begynn med å gå til og navigere til innstillingsdelen. Undersøk nøye hvert konfigurerbart alternativ, inkludert, men ikke begrenset til, intern oppringingingskonfigurasjon, nødanropsparametere, samtalerutingspolic yer, talepostadministrasjon og standardinnstillinger for enheten.

Juster disse globale innstillingene slik at de gjenspeiler organisasjonens retningslinjer og designbeslutninger.

Også, oppsettinnstillinger og bruker- og appmaler.

Pilotmigrasjon

I implementeringsfasen representerer gjennomføring av en pilotmigrering en kritisk milepæl i valideringen av overgangen fra til. Denne piloten innebærer å klargjøre et representativt delsett av brukere på tvers av ett eller flere steder på plattformen, og sikre at den valgte populasjonen gjenspeiler forskjellige brukstilfeller og organisatoriske roller. Parallelt med brukermigrering må viktige samarbeidstjenester, inkludert telefonsvarer, automatiske svartjenester, samtalekøer og jaktgrupper, overføres til sine ekvivalenter for å opprettholde forretningskontinuitet og tjenestefunksjonalitet.

Pilotmigreringen bør utnytte den samme kombinasjonen av Cisco-leverte verktøy og tredjepartsmigreringsverktøy som er planlagt for den bredere organisasjonsdistribusjonen, og sikre at prosessene, automatiseringsarbeidsflytene og integrasjonspunktene blir grundig validert under representative forhold.

Hovedmålene for denne pilotdistribusjonen er todelt: For det første, å validere og finjustere ende-til-ende-overgangsprosess ene, inkludert arbeidsflyter for klargjøring av brukere, prosedyrer for datami grering, og endepunktkonfigurasjoner; og for det andre, å fullstendig verifisere funksjonaliteten til migrerte tjenester under virkelige driftsforhold.

Denne trinnvise tilnærmingen gjør det mulig for prosjektteamet å identifisere og løse eventuelle tekniske eller prosessuelle problemer i et kontrollert miljø, samle tilbakemeldinger fra brukerne om den nye plattformopplevelsen, vurdere effektiviteten til utvalgte migr eringsverktøy og etablere tillit til migreringsm etodikken før de fortsetter med bredere organisatorisk distribusjon.

Innsikten som er oppnådd i løpet av denne pilotfasen er avgjørende for å optimalisere påfølgende migrasjonsbølger og sikre en jevn, risikoredusert overgang for hele bedriften.

Anskaffe PSTN

For å anskaffe PSTN-tjenester for, velg først et PSTN-tilkoblingsalternativ i.

Hvis en organisasjon planlegger å opprettholde hybrid dobbel samtalekontroll (fase 1 i figur Faset an ropsovergang: Hybrid og sky) enten midlertidig eller på ubestemt tid, må de distribuere en eller flere lokale gateways for lokalt PSTN for å tillate anrop mellom og endepunkter.

Hvis en full overgang (fase 2) til skyen er sluttmålet inkludert PSTN, vil enten en Cisco Calling Plan eller et Cloud Connect for alternativ være nødvendig for PSTN.

Arbeid med den valgte leverandøren for å bestille og portere telefonnumre før du konfigurerer dem inn. Bestilling av telefonnumre eller initiering av portbestillinger er bare nødvendig/mulig for lokal PSTN og Cloud Connect for. For Cisco-samtaleplaner startes bestilling og portering fra Control Hub så snart lokasjonen er opprettet, og i land der Cisco Calling Plan er tilgjengelig. Hvis du vil ha mer informasjon om Cisco Calling-planer, kan du se Komme i gang med Cisco-abonnementene.

Som en del av PSTN-implementeringen må du sørge for at leverandøren din har aktivert både innkommende og utgående PSTN-tjenester for posisjonen din. I tillegg kan du utføre testanrop for å bekrefte at samtaler blir rutet riktig gjennom den valgte PSTN-tilkoblingen.

Konfigurer plasseringer

Før du legger til brukere og enheter i, må du klargjøre anropssteder. For hvert sted må en gyldig gateadresse oppgis. I USA og Canada valideres denne adressen og brukes av plattformen til å sende PIDF-LO-posisjonsinformasjon for nødanrop.

Når du konfigurerer lokasjoner som bruker lokal PSTN, må du konfigurere de lokale gatewayene tilsvarende. I må en stamme og en rutegruppe opprettes for hver lokal gateway, og rutegru ppen tilordnes deretter som PSTN-valget for plasseringen. Cisco anbefaler på det sterkeste at du alltid velger en rutegruppe som PSTN-valg, da denne tilnærmingen lar deg enkelt legge til flere trunker i fremtiden, som støtter både skalerbarhet og redundans. Cisco anbefaler også å aktivere dual-identity og P-Charge-Info-støtte på alle PSTN-trunker, siden dette forenkler identifiseringen av den fakturerbare parten for utgående direkte eller omdirigerte samtaler. Hvis PSTN-leverandøren bruker en annen overskrift for fakturering, kan du kopiere informasjonen fra P-Charge-Info-overskriften på den lokale gatewayen til den nødvendige faktureringsoverskriften.

For steder som bruker Cloud Connect for eller Cisco Calling Plan som sitt PSTN-alternativ, velger du ganske enkelt det respektive PSTN- valget for stedet under oppsettet. Hvis plasseringen bruker enten Cloud Connect for eller lokal PSTN, må du legge til telefonnumrene som ble bestilt i forrige trinn. Numre kan legges til som inaktive hvis du ikke vil at de skal inkluderes i samtal erutingen med en gang; du kan aktivere disse numrene senere når de tilordnes brukere eller funksjoner.

Det er viktig å alltid angi hovednummeret for hvert sted. Hovednummeret kan tilordnes enten en bruker eller en funksjon, for eksempel en automatisk ledsager. For å aktivere talepost på stedet, må du sørge for å angi telefon svarerpilotnummeret, også kjent som taleportalnummeret.

Ytterligere innstillinger for anropssteder inkluderer konfigurering av nødanropdetaljer, for eksempel nødnummeret, varsling salternativer og forbedrede nødanropsfunksjoner. Du bør også se gjennom og justere opptaksinnstillinger, språkpreferanser og enhet skonfigurasjoner etter behov for hvert sted. Hvis organisasjonen bruker forkortet internett-oppringing med betydelige virksomhets numre, må du huske å konfigurere en unik områdekode for stedet i de interne oppringingsinnstillingene. Til slutt, hvis ekstern oppringing krever et utgående nummersiffer, må du sørge for å angi dette i innstillingene for ekstern oppringing. Når et utgående nummersiffer er konfigurert, anbefaler Cisco å aktivere håndhev ing av utgående nummersiffer for å sikre konsistens.

Integrasjon med lokal samtalekontroll

Hvis du vil integrere med lokal anropskontroll, er det nødvendig å konfigurere trunker, rutegrupper, bedriftsoppringingsplaner og både lokasjonsinnstillinger og globale innstillinger. Begynn med å sette opp trunkene og de lokale gatewayene som er beregnet for sammenkobling med det lokale anropskontrollsystemet. Dette trinnet er bare nødvendig hvis dedikerte trunker er nødvendige. Hvis eksisterende trunker og rutegrupper er tilstrekkelige for distribusjonen, kan de brukes på nytt for den lokale sammenkoblingen uten ytterligere konfigurasjon.

Når stammene og rutegruppene er etablert, fortsetter du med å opprette virksomhetsnummerplanene og tilordne den aktuelle rutegruppen som destinasjon for hver nummerplan. Når integrering involverer flere lokale anropskontrollsystemer koblet gjennom forskjellige trunker, vil det være nødvendig med flere oppringingsplaner. Det er viktig å sikre at disse nummerplanene bare inneholder mønstrene som er nødvendige for å dirigere anrop til lokale destinasjoner.

Hvis distribusjonen krever støtte for ukjent utvidelsesruting, bør denne funksjonen være aktivert på stedsnivå. I tillegg, når ukjent utvidelsesrut ing er aktivert, må du angi maksimal ukjent forlengelseslengde i delen An ropsruting mellom og lokaler i innstillingene for anropstjenester i. Dette sikrer sømløs samtaleruting og riktig håndtering av utvidelsesbaserte oppringings scenarier i ditt integrerte miljø.

Overfør brukere i grupper

Når du overfører brukere fra til, kan du kanskje ikke flytte alle brukere samtidig. Dette kan skyldes flere årsaker, inkludert, men ikke begrenset til, antall nettsteder eller brukere, hvor lang tid det tar å overføre et nettsted og/eller en gruppe brukere på en gang, begrenset IT- eller nettstedsressurs for å støtte endringsvinduet, varigheten av endringsvinduet, endringens kompleksitet osv.

Når du overfører brukere i faser, er det viktig å identifisere hvilke brukere som må migrere sammen i samme batch. Det primære målet er å migrere brukere sammen som har avhengigheter med hverandre for sine samtaletjenester og funksjoner. Du vil sikre at alle samtal efunksjonene deres (Eksempel - Anropskøer) er fullt funksjonelle på som de var før overgangen på.

Selv om du implementerer samtalesamarbeid mellom og med lokale gateways, kan du ikke dele delte tjenester eller funksjoner på tvers av denne tilkoblingen. Derfor må du identifisere avhengighetene mellom brukere ved å se på funksjoner som:

Overvåke andre brukere som bruker BLF-er

I samme jaktpilot, anropskø osv

Delte linjer

Bruke henting av anrop

Bruke de samme telefonnummerene

Intercom

Eksekutiv/Administrator.

Et eksempel kan være en bruker som er en del av en Hunt Group som blir overført til. Denne brukeren vil gå over til med Hunt Group og med alle andre medlemmer av Hunt Group. Derfor, etter overgangen kan Hunt Group og dets medlemmer lykkes med å svare på samtaler på den nye plattformen.

Dette blir mer utfordrende når brukere er koblet til forskjellige grupper av brukere for forskjellige samtaletjenester og funksjoner. Dette vil kreve overgang av mer enn én gruppe brukere og en ringetjeneste til samtidig.

Bruk utdataene fra Migreringsinnsiktsverktøyet eller tredjepartsverktøyet du brukte i forberedelsesfasen til å bestemme hvilke brukere og funksjoner som skal grupperes sammen. Denne utgangen skal ha blitt brukt til å utvikle overføringsplanen din, og vil gi deg innsikt i hvordan du vil gruppere brukere og funksjoner som trenger å gå over sammen.

De viktigste trinnene når du overfører en gruppe brukere er:

Identifisere brukere som skal migreres sammen

Bekreft at alle brukere er inne

Bekreft at alle TN-er for brukerne finnes i

Bekreft riktig telefonnummerformat i katalogen

Kontroller at lisensierings- og innstillingsmalen for brukergruppene er riktig konfigurert

Verifisere eller konfigurere alle anropstjenester og funksjoner for bruker gruppen (før eller under overgangen etter behov)

Legg til brukere i gruppen av anropsaktiverte brukere i bedriftskatalog en

Utnytte verktøy - bruker- og funksjonsmigreringsverktøy og/eller tredjepartsverktøy

Deaktiver/slett bruker-/enhetskatalognummer og anropsfunksjoner/tjenester på etter overgangen.

Når du har overført en gruppe brukere, tester du et delsett av brukerne for å bekrefte at alle anropsfunksjonene og tjenestene deres fungerer som de skal. Hvis anropsfunksjoner som samtalekø, jaktgrupper osv. overføres med gruppen av brukere, må du teste disse anropstjenestene for riktig funksjonalitet.

Arbeidsområder

I refererer et arbeidsområde til et delt sted (for eksempel et konferanserom, møteplass eller hot desk) som kan tilordnes enheter, utvidelser og brukere. I motsetning til tradisjonelle Unifed CM- telefoner, er arbeidsområder:

Plasseringssentrisk: bundet til fysiske rom.

Enhetsfleksibel: kan ha en eller flere enheter (skrivebordstelefoner, tavler, etc.).

Når arbeidsområder er identifisert som en del av overgangen til, kan de legges til under Enheter. Hvert arbeidsområde trenger en enhetstilordning, og hvis de allerede er inneUnified CM, må de tilbakestilles eller klargjøres på nytt. funksjoner som telefonsvarer, viderekobling og henting av anrop kan aktiveres eller deaktiveres, og retningslinjer kan brukes for videosamtaler, anropsparkering og mobilitet etter behov. Test hvert arbeidsområde ved å ringe interne og eksterne samtaler, teste video-, konferanse- og mobilitets funksjoner. Til slutt, gi brukerne beskjed om eventuelle gjeldende prosesser for arbeidsområdeenheter og bestillinger.

Hvis du vil ha mer informasjon om arbeidsområder i, kan du se Arbeid sområder.

Tilveiebringsenheter

Telefoner som for øyeblikket er registrert på, må migreres til som en del av skyovergangen. For å gjøre migreringen så enkel som mulig med minimal sjanse for feil, anbefaler Cisco å migrere fysiske nettsteder eller avdelinger samtidig. Det kan imidlertid hende du må migrere brukere i grupper på grunn av funksjonsavhengigheter. Se avsnittet Over føre brukere i grupper for mer informasjon.

Alle støttede telefoner som du trenger å gå over fra, må konfigureres som bruker eller arbeidsområde, og den fysiske telefonen må konfigureres på nytt for å registrere deg med . I tillegg trenger telefonene i 7800- og 8800-serien sin firmware oppgradert fra Enterprise- firmware til Multiplatform Phone (MPP) firmware. Denne prosessen inkluderer lasting av overgangs firmware før du laster inn MPP-fastvaren som kreves for registrering. Det krever også riktig migrasjonslisens. Cisco har forbedret denne prosessen de siste årene for å gjøre det lettere for deg å oppgradere Enterprise-firmwaretelef oner til MPP-firmware. Hvis du vil ha mer informasjon om trinnene for å fullføre fastvareoppgraderingen, kan du se Konvertere IP-telefoner i Cisco 7800- og 8800-serien mellom Enterprise- og MP P-fastvare.

I tillegg til trinnene som er beskrevet i denne artikkelen, har du et innebygd verktøy, Overfør telefonen til Webex Calling, som du kan bruke til å migrere 7800- og 8800-telefonene fra Enterprise til MPP-fastvare. Dette verktøyet lar deg også legge telefonene til og tilordne dem til de aktuelle brukerne eller arbeidsområdene. Hvis du vil ha mer informasjon om verktøybruk, kan du se Overføre telefonen.

For telefoner i 9800-serien som er registrert med ovennevnte fastvaremigreringskrav gjelder ikke. Disse telefonene kjører PhoneOS, som støttes av både og. For å overføre disse telefonene til, må du legge dem tilWebex Calling, tilordne dem til en bruker eller et arbeidsområde og deretter tilbakestille telefonene til fabrikken. PhoneOS-oppstartssekvens for registrering Figur nedenfor viser oppstartssekvensen for PhoneOS og hvordan telefonen vil registrere seg når den er blitt lagt til, selv om telefonen fremdeles er klargjort og/eller DHCP-alternativer (Eksempel - 150) er i bruk.

PhoneOS oppstartssekvens for registrering

støtter fabrikkinnstilling av PhoneOS-enheter for å tillate Zero-Touch-onboarding til. administratorer kan eksternt tilbakestille 9800- og 8875-telefonene via CUCM-administrasjons sidene, noe som eliminerer behovet for fysisk tilgang til telefonene for å ombord telefonene til. Denne funksjonen støttes med enhetspakkene fra 9. september 2025:

CUCM v15 — Unified Communications Manager versjon 15

CUCM v14 - Unified Communications Manager versjon 14.

For mer informasjon om registreringsprosessen for 9800-serien, se Registrerings prosess.

I tillegg til Cisco IP-telefoner, kan det være nødvendig med klargjøring av andre enheter som analoge telefon adaptere (ATA), trådløse (Wifi, DECT) telefoner, videoenheter, stemmegateways og tredje ^part senheter og -telefoner. Mange av disse enhetene har ikke en fastvareoppgraderingsbane som IP-telefonene for å overføre dem fra bedriftsfirmware til sky fastvare. Derfor vil du klargjøre hver av disse enhetene i Control Hub. Noen av disse kan ikke overføres til, og den tilsvarende modellen må erstatte den (f.eks. ATA 191/192) og andre vil kreve manuell rekonfigurasjon og/eller programvareendringer.

Talegatewayer — Hvis du vil migrere den lokale gatewayen, kan du se Overføre lokal gateway.
Hvis du vil ha mer informasjon om hvordan du konfigurerer talegatewayen VG400, VG410 eller VG420 i Control Hub, kan du se Lokal gateway

Analog telefonadapter (ATA) - For å komme i gang med Cisco ATA 191 og 192, se Cisco ATA.

Trådløs Wifi-telefon - Hvis du vil integrere trådløs telefon 840 og 860, kan du se Integrere trådløs Webex telefon.

Trådløse DECT-telefoner - For å komme i gang med den nye Cisco IP DECT 6800-serien, se Cisco IP DECT.

Hvis du vil bygge og administrere digitalt DECT-nettverk i Control Hub, kan du se Administrer DEC T-nettverk

Hvis du vil ha mer informasjon om Cisco IP DECT 6800, kan du se Implementeringsveiledning

Tred ^je partsenheter og -telefoner - Arbeid med tredje ^part sleverandører om krav til enhet/telefon og prosessen for å migrere eller erstatte dem for å støtte.

Konfigurer funksjoner

Eventuelle anropsfunksjoner som kreves må klargjøres før eller under overgangen. Som diskutert i delen Overfør brukere i grupper, må anropsfunksjonene konfigureres og overføres når brukerne som bruker dem blir overført.

Hvis du vil ha mer informasjon om hvordan du konfigurerer hver av funksjonene, kan du se de tilsvarende hjelpeartiklene for konfigurasjon.

Automatiske svartjenester — Hvis du vil administrere automatiske svartjenester, kan du se Automatiske svartjenester

Anropsparkering - Hvis du vil administrere anropsparkering, kan du se An rop sparkering

Henting av anrop — Hvis du vil konfigurere gruppen for henting av anrop, kan du se H enting av anrop

Anropskøer — Hvis du vil konfigurere anropskø, kan du se An rop skø

Jaktgrupper — Hvis du vil administrere jaktgrupper, kan du se Administrer jakt gruppe

Driftsmoduser — Hvis du vil ringe ruting basert på driftsmoduser, kan du se Anropruting basert på driftsmoduser

Personsøkingsgrupper — Hvis du vil konfigurere en personsøkingsgruppe, kan du se Konfigurere en personsøkingsgruppe

Opptak — Hvis du vil administrere anropsopptak for, kan du se Administrer opptak

Enkeltnummerrekkevidde — Hvis du vil konfigurere enkeltnummerrekkevidde (kontor hvor som helst), kan du se Konfigurere enkeltnummer

Talepostgruppe — Hvis du vil administrere en delt talepost og en innkommende faksboks for, kan du se Administrere telefonsvarer.

Godkjenningstesting

Godkjenningstesting sikrer at det migrerte miljøet oppfyller funksjonskravene, fungerer som forventet, og leverer en sømløs brukeropplevelse på tvers av alle kommunikasjonsarbeidsflyter. Denne validerings prosessen er mangesidig, og dekker alt fra brukerklargjøring og nummertildelinger til den operative ytelsen til avanserte anropsfunksjoner.

Denne delen gir eksempler og fremhever viktige aspekter å vurdere under aksepttesting; men, det er ikke ment å tjene som en uttømmende eller omfattende sjekkliste.

Brukerklargjøring og nummertildeling

Et grunnleggende aspekt ved aksepttesting innebærer å verifisere at alle brukere er klargjort nøyaktig og fullstendig innenfor. Dette krever en grundig sammenligning mellom source () -katalogen og den nylig etablerte brukerbasen for å sikre at hver brukerkonto, sammen med tilknyttede attributter som ut videlsesnumre og DID-tildelinger (Direct Inward Dial), er blitt korrekt migrert. Fullstendighet av klargjøring er avgjørende, ikke bare for drift fra dag én, men også for lø pende administrasjon og støtte.

Validering av nummertildeling inkluderer bekreftelse av at hver bruker er tildelt riktig utvidelsesnummer og eksternt nummer, og at disse tallene ruter riktig i både interne (på nett) og eksterne (PSTN) anropsflyter. Det er viktig å se etter eventuelle overlappinger, manglende tildelinger eller feilkonfigurasjoner som kan føre til anroprutingsfeil eller tjenesteavbrudd.

PSTN Anropsflyt og presentasjon av anrops-ID

En robust aksepttestprosedyre må omfatte ende-til-ende- validering av PSTN-anropsflyter. Dette inkluderer både innkommende og utgående anropsscenarier . For innkommende PSTN-anrop bør testteamet bekrefte at anrop leveres til de tiltenkte endepunktene, enten dette er individuelle brukere, samtalekøer, jaktgrupper eller automatiske svarmenn. Utgående PSTN-anrop må plasseres vellykket, med spesiell oppmerksomhet gitt til riktig levering og presentasjon av innringer-ID-informasjon. Dette innebærer å sikre at riktig innringernavn og nummer vises til eksterne mottakere, i samsvar med organisasjonspolitikk og for skriftskrav.

Testing bør også adressere failover-scenarier, for eksempel håndtering av util gjengelige endepunkter eller nettverksforstyrrelser. Dette bidrar til å bekrefte at fallback-mekanismer og alternativ ruting fungerer som de skal, og oppret tholder tjenestekontinuitet og pålitelighet.

Anropsstrømmer på nettet

Interne eller nettbaserte samtaleflyter danner ryggraden i bedriftskom munikasjon. Godkjenningstesting i dette området bekrefter at samtaler mellom brukere i organisasjonen rutes riktig, med funksjoner som overføring av anrop, hold, videresending og konferanser som fungerer som beregnet. Integriteten til oppringingsplaner, tilkoblingsmuligheter for utvidelse til utvidelse og støtte for retningslinjer for organisasjonsan rop må bekreftes.

Brukersamtalehåndtering og funksjonsvalidering

Et viktig aspekt ved aksepttesting innebærer å validere hvordan brukere håndterer samtaler ved hjelp av og støttede skrivebordstelefoner. Denne prosessen fokuserer på å bekrefte at daglige samtalearbe idsflyter er intuitive og pålitelige, og at brukerne har sømløs tilgang til kjerne funksjonene som er nødvendige for rollene deres. Testing bør vurdere hvor enkelt brukere kan ringe og motta samtaler, administrere hold- og gjenopptaksfunksjoner, og utføre både blinde og rådgivende overføringer. Det er også viktig å verifisere at viderekobling, konferanse og andre avanserte funksjoner, for eksempel parkering og hente samtaler eller aktivere ikke forstyrr, er lett tilgjengelige og fungerer problemfritt.

Opplevelsen bør evalueres for klarhet og respons, med tanke på hvordan brukere samhandler med samtalelogg, telefonsvarer og integrerte kataloger. Ytterligere oppmerksomhet bør rettes mot muligheten til å flytte aktive samtaler mellom enheter og å bruke samtalekontroller effektivt i applikasjonen eller på fysiske telefoner. Det endelige målet er å sikre at sluttbrukeropplevelsen er konsistent, effektiv og fullt ut støtter organisasjonens kommunikasjonsbehov etter migreringen.

Samtalekøer: Agent- og veiledererfaring

Anropskøer brukes ofte til å håndtere scenarier for inngående samtaler med høyt volum. Godkjenningstesting her fokuserer på flere dimensjoner. Først bør det verifiseres at anrop distribueres til agenter i henhold til den konfigurerte kølogikken, slik som round robin, lengst tomgang eller samtidig ring. Presentasjonen av anrop i kø på agent skrivebord må undersøkes for klarhet og brukervennlighet, slik at agenter effektivt kan godta, holde og overføre samtaler.

For veiledere bør skrivebordsopplevelsen evalueres for funksjoner som sanntidsovervåking, samtalefarging og analyse eller inn sikt i køytelse. Dette inkluderer, men er ikke begrenset til, validering av dashbord og rapporteringsverktøy som gir handlingsbare data om samtalefor deling, agentaktivitet og køberegninger.

Jaktgrupper: Samtalefordeling

Jaktgrupper er en nøkkelmekanisme for å distribuere samtaler til forhåndsdefinerte sett med brukere. Godkjenningstesting må bekrefte at anrop rutes til gruppemedlemmer basert på den konfigurerte jaktalgoritmen, og at overløp, videresending, og no-svar scenarier håndteres i henhold til design. Å sikre at gruppemedlemskap og samtalerutingsatferd samsvarer med de som tidligere er etablert i, er avgjørende for operativ konsistens og brukertilfredshet.

Autorespondenter: Kunngjøringer og menyoperasjoner

Autorespondenter representerer frontlinjen for automatisert samtalehåndtering. Testing må dekke avspilling av kunngjøringer, nøyaktigheten av inn spilte hilsener og riktig drift av menytrær. Meny valg skal på en pålitelig måte rute innringere til de aktuelle avdel ingene, enkeltpersoner eller eksterne numre. Testing bør også omfatte ugyldige scenarier eller tidsavbruddsscenarier for å bekrefte at innringere får tydelig veiledning eller blir omdirigert som beregnet.

Talepostoperasjon

Til slutt er telefonsvarerfunksjonalitet avgjørende for brukeropplevelsen. Godkjenningstester bør bekrefte at telefonsvarerbokser er riktig tilordnet og tilgjengelige, både fra organisasjonen og eksternt. Muligheten til å registrere, hente og administrere meldinger må bekreftes, sammen med varsellevering.

Optimaliser

PSTN-migrering til Cloud Connect for

Optimaliser lokal infrastruktur

Bruk analyser og feilsøking

PSTN-migrering til Cloud Connect for

Når alle endepunkter og brukere er migrert til skyanrop, Unified CM er det eneste formålet med å fungere som en transitt mellom PSTN-gatewayene og via lokal gateway. Å fjerne PSTN-gateways,, og Local Gateway fra bildet ved å bruke Cloud Connect for som PSTN-tilgang for alle Webex Calling brukere, har flere fordeler, inkludert kostnads reduksjon og forbedret pålitelighet. Følg disse trinnene for å overføre lokal PSTN-tilgang til Cloud Connect for :

Cloud Connect for partnervalg.

Se listen over Cloud Connect for partnere, og velg blant de tilgjengelige partnerne som er tilgjengelige for organisasjonens beliggenhet.

Cloud Connect for validering.

Før du bytter PSTN-tilgang for lokasjoner til Cloud Connect, bør tilkoblingen til PSTN via den valgte Cloud Connect-partneren verifiseres og valideres. For dette formålet må en testplassering klargjøres med noen testbrukere klargjort på den testplasseringen. PSTN-tilgang for dette test stedet settes deretter til Cloud Connect-partneren før du validerer PSTN-tilkobling ved hjelp av testtelefonene. Etter vellykket validering kan testplasseringen avklares.

Nummerportering.

For å forberede overgangen til Cloud Connect, må det legges inn en portordre for alle numre som for øyeblikket er tildelt PSTN-stammen som avsluttes. Alle numre må overføres til Cloud Connect-partneren. For å opprettholde tilgjengeligheten mellom lokasjoner, må alle antall av alle lokasjoner porteres samtidig .

Bytt til Cloud Connect-partner.

På datoen for overgangen må PSTN-tilgang for alle lokasjoner i settes til Cloud Connected PSTN-leverandøren, og innkommende og utgående tilkobling bør verifiseres.

Som diskutert i PSTN-delen av designkapittelet, kan kunder også velge å flytte PSTN-tilgangen til Cloud Connect for i starten av overgangen ved å bruke PSTN-trunking for hybriddistribusjoner. Hvis du vil ha mer informasjon, kan du se PSTN-trunking for hybriddistribusjoner. Webex Calling I dette tilfellet under overgangen er PSTN-tilgang for via lokal gateway, og etter at alle brukere er flyttet til, er det ikke noe ytterligere PSTN-relatert migreringstrinn annet enn avvikling og de lokale gateway-ene.

Optimaliser lokal infrastruktur

Når alle brukere har blitt overført til og alle endepunkter har blitt overført til skyregistrering (eller er tatt ut av drift), oppdat erer du passende lokal infrastruktur nå som skyanrop er i bruk. Oppdateringer av infrastrukturen inkluderer:

Fjern lokale anropskontroll- og meldings DNS SRV oppføringer fra den lokale DNS-serveren (e), inkludert cisco_uds. _tcp. <domain>, cup_login. _tcp. <domain>. Disse SRV-postene er ikke lenger nødvendige for oppdagelse av klienttjenester.

Fjern kantrelaterte DNS SRV poster fra det offentlige DNS-systemet inkludert collab_edge. _tls. <domain>. Disse SRV-postene er ikke lenger nødvendige for klienttjenesteoppdagelse av kant tjenester for samarbeid.

Oppdater alle relevante DHCP-områder for å fjerne alternativ 66 og alternativ 150 TFTP/oppstartsserveradresser. Disse omfangene er ikke lenger nødvendige for oppdagelse og nedlasting av konfigurasjon for endepunktsamtalekontroll.

Oppdater/fjern passende oppringingingere i Lokal gateway/kube som dirigerer anrop til og fra. Unified CM Disse oppringingsjevnaldrende er ikke lenger nødvendige for lokal samtaleruting.

Slett eller fjern alle virtuelle maskiner og/eller servere i klyngenode. Bruk beregningsressurser og maskinvare på nytt etter behov. Disse ressursene er ikke lenger nødvendige for anropskontroll og kanttjenester.

Slett eller fjern alle virtuelle maskiner og/eller servere i klyngenode. Bruk beregningsressurser og maskinvare på nytt etter behov. Disse ressursene er ikke lenger nødvendige for telefonsvarer og enhetlige meld ingstjenester.

Opprydding: Etter migrering av PSTN-tilgang til Cloud Connected PSTN, kan PSTN-trunker, PSTN-gateways og Local Gateway tas ut av drift.

For alle eksisterende lokale E911-løsninger sletter du alle plasseringer eller numre som har migrert til, og når full overgang er fullført, fjerner du virtuelle programmaskiner eller servere. Bruk beregningsressurser og maskinvare på nytt etter behov. Disse ressursene er ikke lenger nødvendige for nødanrop og lokaliseringstjenester.

DNer som tilhører migrerte brukere bør plasseres i en skjult partisjon for å unngå feil i samtalerutingen og for å sikre at alle CSS-er har prioritert tilgang til skybanen til de samme DNene.

Oppdater den fysiske forsendelsesbare plasseringen og nettverkselementet i horisontmobilitet når endringer skjer. Vanlige aktiviteter som krever oppdateringer er:

Utskifting av nettverksbryter

Utskifting av trådløst tilgangspunkt

Endringer i DHCP-omfang

Fysiske endringer inne i bygningen (hvis det løses til kubikal/kontor)

Fysisk utvidelse eller sammentrekning av kontorlokaler inne i en bygning.

Bruk analyser og feilsøking

gir omfattende analyse- og feilsøkingsfunksjoner for å hjelpe deg med å visualisere og spore distribusjonen. Disse dekker mediekvalitet, detaljert samtalelogg, samtalekø, jakt gruppe, og automatisk svarteanalyse. Et eksempel på mediekvalitetsanalyse er vist i figur mediekvalitetsanalyse.

analyse av mediekvalitet

Under feilsøking kan hvert anrop som gjøres ved hjelp av vises med detaljert informasjon om viktige mediekvalitet og signalrelaterte problemer for å finne medieproblemer så vel som mislykkede anrop, som vist i feilsøking av medi ekvalitet på figuren.

feilsøking av mediekvalitet

Feilsøking kan også integreres med andre Cisco-produkter som ThousandEyes og Meraki- svitsjer for å gi en enda rikere integrert opplevelse i Control Hub. Hvis du vil ha mer informasjon om bruk av Webex Callinganalyser og feilsøking, kan du se Feilsøke an Webex Calling rop i Control Hub.

Introduksjon

Før du begynner

Oversikt

Kjernekomponenter

Oversikt over PPDIO-prosessen

Generell beskrivelse av PPDIO

Bruk av PPDIO for migreringsprosjekter fra Unified CM til Webex Calling

Forberede

Plan

Design

Implementer

Optimaliser

PPDIO-tilbakemeldingsløkker

Migrasjonstilnærming

Før du begynner

Denne veiledningen er ment for team eller enkeltpersoner med erfaring i å konfigurere og administrere Cisco Unified Communications Manager (Unified CM) og Cisco-endepunkter, inkludert IP-bordtelefoner, videoenheter og Jabber-programvareklienter. Gjennom hele dette dokumentet finner du lenker til produkt- og støttedokumentasjon som kan være til hjelp.

Dette dokumentet fokuserer kun på overganger fra Unified CM til Webex Calling flerbruker. Begrepet Webex Calling i dette dokumentet refererer alltid til Webex Calling-multi-tenant.

Før du starter migreringen fra Unified CM til Webex Calling, er det viktig å ha en omfattende forståelse av Webex Calling-løsningen og dens respektive komponenter. En vellykket migrering krever kjennskap til Webex Calling-arkitekturen, tjenestemodeller, distribusjonsalternativer og tilhørende funksjoner for å kartlegge eksisterende Unified CM-arbeidsbelastninger på riktig måte og utforme en effektiv overgangsplan.

En grundig forståelse av følgende Webex Calling-komponenter er viktig for å kunne utforme en effektiv overgangsstrategi og operativ beredskap.

Kontrollsenter

Katalog- og brukerklargjøring

Webex Calling-plattform

Støttede anropsendepunkter

PSTN-tilkoblingsalternativer

Webex Calling-oppringingsplan og nummeradministrasjon

Sikkerhets- og samsvarsfunksjoner.

Hvis du vil ha mer informasjon, kan du se Cisco Preferred Architecture for Webex Calling.

Denne veiledningen vil fremheve verktøy og prosesser som skal brukes gjennom hele overgangssyklusen. En overgang fra lokale samtaler, Unified CM, til en ny skybasert samtaleplattform, Webex Calling, kan imidlertid være en betydelig innsats med potensielle forretningsmessige, tekniske og komplekse utfordringer. For å hjelpe deg med å overvinne disse utfordringene har Cisco noen forskjellige alternativer tilgjengelig for å hjelpe deg på reisen. Det er viktig å gjennomgå informasjonen på Enterprise cloud calling - Calling migration og forstå hvert alternativ og hvordan hvert enkelt muligens kan hjelpe deg med din egen migrering.

Webex-migreringsverktøy: Selvbetjente, gratis verktøy innebygd i Control Hub for å effektivisere overgangen til Webex Calling

Sertifiserte migreringsleverandører: Cisco-validerte programvare- og verktøyleverandører som har utviklet migreringsløsninger for å hjelpe Webex-partnere og -kunder med komplekse og store migreringer. Disse løsningene kan bidra til å forenkle, administrere og akselerere overgangen til Webex Calling.

Webex-oppsetthjelp: en Cisco-ledet migreringstjeneste som veileder kunder og partnere gjennom Webex Calling-distribusjonen og -konfigurasjonen, som er nødvendig for å kunne migrere Unified CM-brukere og -tjenester til Webex Calling.

Oversikt

Med veksten av skybaserte samarbeidstjenester ønsker flere kunder å flytte sine eksisterende samarbeidsarbeidsmengder til skyen, gitt løftene om reduserte totale eierkostnader, forenklet administrasjon, kontinuerlig funksjonslevering, økt skalering og overlegen pålitelighet som er iboende i skybaserte tjenester. Når kunder ønsker å gå over fra lokale til skybaserte samarbeidstjenester, er det viktig at de forstår hva overgangen innebærer, og hvilke trinn som kreves for å gjennomføre overgangen.

Formålet med dette dokumentet er å gi veiledning om distribusjon for kunder som spesifikt ønsker å gå over fra lokal Unified CM til Webex Calling i skyen. Denne distribusjonsveiledningen forutsetter at leseren har en grunnleggende forståelse av anropsovergangen mellom Unified CM og Webex Calling, inkludert hva som endres når denne overgangen gjøres og hva forskjellene er når man flytter anropsarbeidsmengden fra lokalt til skyen. Før du fortsetter, sørg for at du har gjennomgått og er kjent med informasjonen som er tilgjengelig i Overgangskartet. Dette overgangskartdokumentet gir informasjon om endringene og forskjellene i denne overgangen.

Som vist i figur Arkitektur for lokalt samarbeid: Samtalekontroll og fjerntilgang, en typisk lokal implementering inkluderer ulike samarbeidsinfrastrukturkomponenter på nettverket, en samtalekontrollplattform, en kantplattform, maskinvare- og programvareendepunkter, og i noen tilfeller til og med konferanse- og planleggingsplattformer. I Cisco-arkitekturen vil dette inkludere Unified CM for samtalekontroll, Expressway for fjerntilgang og bedrift-til-bedrift (B2B) kanttjenester, Cisco Meeting Server / Cisco Meeting Management for lokale konferanser, Unity Connection for talemeldinger og brukerrettet maskinvare (Cisco IP-telefoner, Cisco Desk- og Room-videosystemer) og programvare (Cisco Jabber) IP-baserte endepunkter. Disse komponentene kan variere noe i enkelte miljøer, men dette er utgangspunktet for overgangen som er beskrevet i resten av dette dokumentet.

Lokal samarbeidsarkitektur: samtalekontroll og fjerntilgang

Arkitekturen vist i figur Arkitektur for lokalt samarbeid: Samtalekontroll og fjerntilgang er basert på den foretrukne arkitekturen (PA) for Cisco Collaboration Enterprise On-Premises-distribusjoner. Hvis du vil ha mer informasjon om Enterprise On-premise, kan du se Ciscos foretrukne samarbeidsarkitekturer.

Før: Tabellen Komponenter for lokal anropsinfrastruktur viser nøkkelelementene i den lokale arkitekturen før overgang til Webex Calling i skyen.

Tabell 1. Før: Komponenter for lokal anropsinfrastruktur
Produkt Beskrivelse

Enhetlig CM Lokal samtalekontroll som tilbyr enhetsregistrering og samtalerutingstjenester

Cisco Expressway-C/E Kantinfrastruktur som tilbyr mobil og fjerntilgang (MRA) og bedrift-til-bedrift (B2B)-funksjonalitet, slik at eksterne endepunkter kan koble seg sikkert til utenfra organisasjonen. Expressway distribueres parvis for å gi brannmurgjennomgang for eksterne endepunkter.

Cisco Meeting Server (CMS), Cisco Meeting Management (CMM) og Cisco Telepresence Management Suite (TMS) Lokal infrastruktur for tale-, video- og nettkonferanser som tilbyr flerpunktsmøter, møteadministrasjon og planleggingsmuligheter. [Optional]

Cisco Unity-tilkobling Lokal talemeldingsplattform som tilbyr talemeldinger og enhetlige meldingsfunksjoner. [Optional]

Cisco Desk, Cisco Room, Cisco Board, Cisco IP-telefoner og Cisco Jabber IP-baserte enheter registrert i Unified CM og som tilbyr tale- og videosamtaler

Som illustrert i figur Overgangsbeslutning: Lokale anrop til Webex Calling, kunder som har en lokal anropskontroll med Unified CM og IP-endepunkter for skrivebord og video, kan velge å overføre arkitekturen til en Webex Calling-skyarkitektur.

Beslutningen må tas basert på kundens funksjonalitetskrav. Kunder som har følgende krav bør vurdere dette nøye før de tar denne avgjørelsen, og kan til slutt bestemme seg for å beholde samtalekontrollen lokalt:

Telefonmodeller støttes ikke av Webex Calling

Komplekse eller mange integrasjoner med andre lokale systemer eller løsninger, spesielt der det er vanskelig å replikere disse integrasjonene med Webex Calling eller det ikke finnes tilsvarende alternative løsninger.

Kompleks oppringingsplan, svært detaljerte tjenesteklasser eller begge deler

Restriktiv, begrenset eller upålitelig internettilgang

Strenge retningslinjer for personvern og eierskap

Samsvarskrav for medieopptak og -lagring på stedet eller i landet

Tredjepartsintegrasjoner uten en brukbar alternativ Webex Calling-integrasjon

Kontaktsenterintegrasjoner der kontaktsenteret ikke flyttes til skyen ennå.

Overgangsbeslutning: Lokale anrop til Webex Calling
Kunder som ønsker å begynne å bruke skytjenester for samtaler, bør vurdere Webex Calling. Denne skytjenesten for anrop lar kunden utnytte Webex globale arkitektur for skalering og tilkobling. Deltakere på bedriftsnettverket og eksterne deltakere utenfor bedriftsnettverket kan kommunisere ved hjelp av IP-baserte maskinvareendepunkter and/or stasjonære eller mobile myke klientapplikasjoner.

Dette dokumentet fokuserer på kunder med Unified CM-anropskontrolldistribusjoner som ønsker å forstå de generelle trinnene, hensynene og kravene for å aktivere Webex Calling-distribusjon som beskrevet i neste avsnitt.

Kjernekomponenter

Målarkitekturen for denne migreringen inkluderer flere nye komponenter. Dette inkluderer Webex Calling-tjenesten for skybaserte anrop, Webex-appen, Cisco Directory Connector for identitetsintegrasjon og Local Gateway (LGW) for PSTN-tilgang, samt integrering av lokale anrop i skyen. Cisco Calling Plans eller Cloud Connected PSTN (CCP) tilrettelagt av en Cloud Connect for Webex Calling-partner er ytterligere alternativer for PSTN-tilgang.

Som vist i figur Etter: Webex Calling Architecture, de nye komponentene (Webex Calling, Directory Connector, Local Gateway og Survivability Gateway) legges til den eksisterende lokale distribusjonen.

Etter: Webex-anropsarkitektur

Etter: Tabellen over komponenter i infrastrukturen for skyanrop viser de nye elementene i arkitekturen etter overgangen til Webex.

Tabell 2. Etter: Komponenter for infrastruktur for skyanrop
Produkt Beskrivelse

Webex-anrop Skybasert samtaletjeneste levert fra Webex-plattformen og tilbyr endepunktregistrering og samtaleruting

Cisco Directory Connector Windows-applikasjon som kjører på en Windows-domenemaskin og tilbyr identitetssynkronisering mellom bedriftens lokale Active Directory og identitetslageret til Webex-organisasjonen.
For kunder som går over fra lokal Active Directory til Entra ID, bruker identitetsintegrasjonen med Webex i stedet for Cisco Directory Connector Entra ID Wizard-appen.

Lokal gateway En lokal gateway fungerer som en bro mellom en kundes lokale enhetlige kommunikasjonsnettverk og Webex Calling-skyen. Den kan distribueres lokalt eller driftes av en partner, og leverer PSTN-tilgang for skyregistrerte endepunkter samt anropsintegrasjon mellom Unified CM-registrerte og skyregistrerte endepunkter. Cisco IOS-XE Integrated Services Router (ISR 1100- og 4000-serien), Cisco Catalyst 8200/8300 Serien, Cisco Catalyst 8000V Edge-programvare og diverse sertifiserte tredjeparts Session Border Controllers (SBC-er) kan brukes som en LGW for en faset migreringsmetode.

Overlevelsesportal Survivability Gateway (SGW) er en lokal nettverks-IOS-XE-basert gateway som tilbyr reserveoppringingstjenester til Webex Calling-endepunkter på stedet under nettverksbrudd.

Cisco-anropsabonnement, Cloud Connect for Webex Calling Cisco Calling Plan og Cloud Connect for Webex Calling er skybaserte alternativer for PSTN-tilgang for Webex Calling-endepunkter. PSTN-tilgang tilrettelegges av en PSTN-leverandør i skyen og krever ikke lokalt utstyr.

Webex-appen Klientapplikasjon som kjører på skrivebords-OS (Windows, Mac) eller mobil-OS (Android, iOS) og er registrert direkte på Webex Calling-plattformen for ringefunksjonalitet.

Oversikt over PPDIO-prosessen

PPDIO-prosessen står for Forbered, Planlegg, Design, Implementer og Optimaliser. Det er en strukturert Cisco-metodikk som veileder prosjekter fra innledende vurdering til kontinuerlig forbedring, og sikrer effektive og vellykkede implementeringer eller migreringer.

PPDIO-prosessen

Generell beskrivelse av PPDIO

Forberede: Vurder dagens miljø, innhent krav og samordne interessenter for å etablere et solid fundament.

Plan: Utvikle detaljerte prosjektplaner, inkludert tidslinjer, ressurser og strategier for risikoredusering.

Design: Utvikle målløsningen skreddersydd for forretningsmessige og tekniske behov.

Implementer: Utfør utrullingen eller migreringen i henhold til designet, og valider funksjonalitet og ytelse.

Optimaliser: Kontinuerlig forbedre løsningen etter implementering ved å overvåke ytelse, forbedre konfigurasjoner og utnytte automatiserings- og integrasjonsverktøy.

Bruk av PPDIO for migreringsprosjekter fra Unified CM til Webex Calling

Ved overgang fra Unified CM til Webex Calling gir PPDIO-prosessen en tydelig plan for å sikre en smidig og effektiv overgang:

Forberede

Vurder det eksisterende Unified CM-miljøet og migreringsberedskapen

Samle detaljerte data om brukere, enheter, nettverk og avhengigheter

Samle inn stedsdetaljer, inkludert adresse for nødberedskap, antall brukere, internettilgang og PSTN-tilgang.

Identifiser risikoer og definer prosjektets omfang for å samkjøre alle interessenter.

Plan

Lag en omfattende migreringsplan med batchplaner, ressurstildelinger og tidslinjer

Definer oppgaver som oppgraderinger av enhetsfastvare, lisensklargjøring og brukerintroduksjon

Koordiner migreringsvinduer med Cisco og partnere for å minimere avbrudd.

Design

Tilordne gjeldende Unified CM-konfigurasjoner, oppringingsplaner og brukerprofiler til Webex Calling-ekvivalenter

Design Webex Calling-miljøet, inkludert PSTN-strategi (midlertidig og endelig), plasseringer, brukerroller og integrasjonspunkter som lokal gateway (CUBE) og katalogsynkronisering

Planlegg for sameksistensscenarioer der Unified CM og Webex Calling opererer samtidig under migrering.

Implementer

Bruk migreringsverktøy for Control Hub sammen med tredjepartsverktøy for å utføre endringer i enhetsfastvaremodus, funksjonskonfigurasjon og brukermigreringer.

Bruk masseoperasjoner og klargjøring ved hjelp av Webex API-er for å effektivisere storskala migreringer og konfigurasjoner

Utfør lisensklargjøring, enhetsregistrering og konfigurasjonsoppdateringer

Valider migreringsvellykket gjennom testing og driftsverifisering.

Optimaliser

Kontinuerlig overvåke Webex Calling-ytelsen og brukeropplevelsen

Avgrens konfigurasjoner og arbeidsflyter basert på driftsdata og tilbakemeldinger

Utnytt automatiserings- og integrasjonsmuligheter for å forbedre effektivitet og skalerbarhet

Avvikle eldre Unified CM-komponenter etter behov og gi kontinuerlig støtte for daglig drift.

Denne forbedrede PPDIO-tilnærmingen sikrer en kontrollert, transparent og effektiv migrering fra Unified CM til Webex Calling, og utnytter Ciscos verktøy, API-er og partnerøkosystem for å opprettholde forretningskontinuitet og forbedre samarbeidsfunksjoner.

PPDIO-tilbakemeldingsløkker

Oversikten på høyt nivå som er vist i figur Iterasjoner under utføring av PPDIO illustrerer en enkelt tilbakekoblingssløyfe fra optimaliserings- - fasen tilbake til forberedelses- -fasen. Dette betyr at det etter den første implementeringen er en kontinuerlig mulighet for kontinuerlig forbedring. Hver optimaliseringssyklus kan identifisere nye krav eller områder for forbedring, som kan håndteres gjennom påfølgende prosjekter eller initiativer. Disse individuelle prosjektene følger igjen den etablerte PPDIO-livssyklusen (Forbered, Planlegg, Design, Implementer, Optimaliser). Denne iterative tilnærmingen sikrer at systemet forblir i samsvar med utviklende forretningsmål og teknologiske fremskritt, og fremmer en kultur med kontinuerlig forbedring og tilpasningsevne.

Iterasjoner under kjøring av PPDIO

Under gjennomføringen av PPDIO-prosessen er det vanlig at funn i senere fasene nødvendiggjør revurdering og potensielt revisjon av beslutninger tatt i tidligere stadier. For eksempel kan problemer som oppstår i implementeringsfasen, som identifisering av designuklarheter eller manglende detaljer, avsløre at visse aspekter ikke ble fullt ut adressert i designfasen. I slike tilfeller blir det nødvendig å iterere tilbake til den relevante tidligere fasen for å løse disse problemene før man fortsetter. Denne iterative tilbakemeldingsmekanismen, som illustrert i figur Enhetlig CM-assistert PPDIO-prosess, sikrer at løsningen blir grundig validert og forbedret, noe som til slutt bidrar til en mer robust og effektiv utrulling.

Enhetlig CM-assistert PPDIO-prosess

Når man foretar en overgang fra Unified CM til Webex Calling, kan hver fase av PPDIO-prosessen dra betydelig nytte av informasjon samlet inn fra det eksisterende Unified CM-miljøet. For eksempel kan omfattende oversikter over brukere, telefonnumre, ringefunksjoner og komponenter for oppringingsplaner hentes ut fra den gjeldende Unified CM-konfigurasjonen. Disse dataene supplerer informasjon gitt direkte av interessenter og bidrar til å effektivisere planleggings- og designaktiviteter. Å utnytte passende verktøy for å automatisere datautvinning og -analyse forbedrer ikke bare nøyaktigheten, men akselererer også den totale prosessen. Ved å bruke innsikt fra den eksisterende distribusjonen kan overgangen til Webex Calling utføres mer effektivt enn en tradisjonell nyetablert implementering, samtidig som den strukturerte PPDIO-metodikken overholdes. Denne prosessen er illustrert i figur Enhetlig CM-assistert PPDIO-prosess.

Migrasjonstilnærming

Når du planlegger overgangen fra lokal Unified CM til Webex Calling, må du bestemme hvordan du vil gå frem for denne reisen. Først må du bestemme om migreringen skal være en hurtigklipp (alt på en gang) eller en faset tilnærming (migrer grupper av users/devices over en lengre periode).

Å gjøre en flash-cut -migrering flytter alle brukerne og enhetene dine raskest. Med denne metoden flytter du alle brukere og enheter fra lokal Unified CM til Webex Calling samtidig. I hovedsak er det ett enkelt migreringsvindu for alle brukere og enheter. Etter at denne migreringen er fullført, vil alle brukerne og enhetene dine være på Webex Calling-plattformen, og all Unified CM-infrastrukturen din kan avvikles. Mange organisasjoner kan imidlertid ikke bruke denne tilnærmingen på grunn av omfanget og størrelsen på samtaledistribusjonen sin.

Den andre tilnærmingen er en faset migrering. De fleste organisasjoner vil bruke denne tilnærmingen, da den gir bedre kontroll, administrasjon og skalering med migreringen. Den er også bedre egnet for større UC-implementeringer. and/or distribusjoner på tvers av flere regioner. Derfor fokuserer dette dokumentet på den fasede tilnærmingen med to trinn i overgangen.

Som vist i figur nedenfor, faseovergang: Hybrid og sky, den første overgangsfasen (fase 1) resulterer i en sameksistensdistribusjon med doble anropsmiljøer. I denne fasen blir noen brukere, enheter og myke klienter overført til Webex Calling, mens andre fortsatt er på den lokale Unified CM-anropskontrollen. Den siste overgangsfasen (fase 2) resulterer i et rent skybasert samtalemiljø der alle brukere, enheter og programvareklienter er fullstendig overført til Webex Calling-plattformen.

Hvor lang tid det tar for en organisasjon å gå helt over til skyanrop, vil variere basert på den nåværende distribusjonen. I noen tilfeller kan en organisasjon foreta den første overgangen og forbli i sameksistensfasen med dobbel samtalekontroll (fase 1) i en lengre periode (måneder eller til og med år), mens i andre tilfeller kan en organisasjon gå over til Webex Calling (fase 2) på svært kort tid (uker eller måneder). Dette dokumentet er ment å dekke begge fasene (fase 1 – sameksistens og fase 2 – fullstendig overgang).

Fasevis overgang til samtaler: hybrid og sky

Det er mulig at noen organisasjoner vil opprettholde en sameksistens-distribusjon av dobbel samtalekontroll på ubestemt tid uten planer om noen gang å gå helt over til skysamtaler.

Den andre vurderingen er hvordan du vil overføre brukere, enheter og programvareklienter fra den lokale samtalekontrollen til den skybaserte samtalekontrollen. Den anbefalte tilnærmingen er en 3-faset overgang. Figuren Anbefalt 3-faseovergang nedenfor deler denne tilnærmingen inn i de 3 fasene.

Anbefalt 3-faseovergang

Før migrering: Denne fasen fokuserer på å gjøre både Webex- og Unified CM-miljøene klare for migreringen. Dette handler ikke om spesifikk planlegging eller konfigurasjoner for anrop, men fokuserer på å fullføre aktiviteter som kan gjøres nå og før et Webex Calling-migreringsprosjekt starter. Målet er å bygge grunnlaget for at de to miljøene skal forberede seg på migrasjonen.

Forberedelse av migrering: Denne fasen er der arbeidet med å forberede overføringen til Webex Calling begynner. Her må forretningsmessige og tekniske krav gjennomgås og oppdateres. Ikke bare gjør en løft og flytt av det som for øyeblikket er distribuert med Unified CM, og omdefiner i stedet de forretningsmessige og tekniske kravene som bedriften din trenger i dag og i fremtiden ved å utnytte kraften til Webex Calling. I tillegg er dette fasen der du skal fullføre design, konfigurasjonsplanlegging og migrering. planning/schedule.

Migrering (utrulling og avvikling): Denne fasen er der den faktiske migreringen av brukere, enheter, telefonnumre og programvareklienter skjer. Som omtalt ovenfor kan denne fasen fullføres for alle samtidig (flash-cut) eller over flere endringsvinduer (phased-cut). Planer for implementering, opplæring og kommunikasjon med sluttbrukere er avgjørende, slik at brukerne dine er klar over endringene, hvordan de bruker den nye ringeplattformen og vet når endringen vil skje. Det siste trinnet er å avvikle all lokal UC-infrastruktur som ikke lenger er i bruk.

Førmigreringsfasen har aktiviteter (obligatoriske, anbefalte og valgfrie) som du kan begynne å jobbe med umiddelbart. Det anbefales å fullføre disse før heller enn senere, og helst før prosjektet starter. Noen av aktivitetene kan ta lengre tid å fullføre, derfor vil det å starte dem tidligere bidra til å effektivisere selve migreringsprosjektet.

Figuren Aktiviteter før migrering nedenfor fremhever fem spesifikke kategorier av aktiviteter som er relatert til en Webex Calling-migrering.

Aktiviteter før migrasjon

Tabell 1. Før: Komponenter for lokal anropsinfrastruktur
Produkt	Beskrivelse
Enhetlig CM	Lokal samtalekontroll som tilbyr enhetsregistrering og samtalerutingstjenester
Cisco Expressway-C/E	Kantinfrastruktur som tilbyr mobil og fjerntilgang (MRA) og bedrift-til-bedrift (B2B)-funksjonalitet, slik at eksterne endepunkter kan koble seg sikkert til utenfra organisasjonen. Expressway distribueres parvis for å gi brannmurgjennomgang for eksterne endepunkter.
Cisco Meeting Server (CMS), Cisco Meeting Management (CMM) og Cisco Telepresence Management Suite (TMS)	Lokal infrastruktur for tale-, video- og nettkonferanser som tilbyr flerpunktsmøter, møteadministrasjon og planleggingsmuligheter. [Optional]
Cisco Unity-tilkobling	Lokal talemeldingsplattform som tilbyr talemeldinger og enhetlige meldingsfunksjoner. [Optional]
Cisco Desk, Cisco Room, Cisco Board, Cisco IP-telefoner og Cisco Jabber	IP-baserte enheter registrert i Unified CM og som tilbyr tale- og videosamtaler

Tabell 2. Etter: Komponenter for infrastruktur for skyanrop
Produkt	Beskrivelse
Webex-anrop	Skybasert samtaletjeneste levert fra Webex-plattformen og tilbyr endepunktregistrering og samtaleruting
Cisco Directory Connector	Windows-applikasjon som kjører på en Windows-domenemaskin og tilbyr identitetssynkronisering mellom bedriftens lokale Active Directory og identitetslageret til Webex-organisasjonen. For kunder som går over fra lokal Active Directory til Entra ID, bruker identitetsintegrasjonen med Webex i stedet for Cisco Directory Connector Entra ID Wizard-appen.
Lokal gateway	En lokal gateway fungerer som en bro mellom en kundes lokale enhetlige kommunikasjonsnettverk og Webex Calling-skyen. Den kan distribueres lokalt eller driftes av en partner, og leverer PSTN-tilgang for skyregistrerte endepunkter samt anropsintegrasjon mellom Unified CM-registrerte og skyregistrerte endepunkter. Cisco IOS-XE Integrated Services Router (ISR 1100- og 4000-serien), Cisco Catalyst 8200/8300 Serien, Cisco Catalyst 8000V Edge-programvare og diverse sertifiserte tredjeparts Session Border Controllers (SBC-er) kan brukes som en LGW for en faset migreringsmetode.
Overlevelsesportal	Survivability Gateway (SGW) er en lokal nettverks-IOS-XE-basert gateway som tilbyr reserveoppringingstjenester til Webex Calling-endepunkter på stedet under nettverksbrudd.
Cisco-anropsabonnement, Cloud Connect for Webex Calling	Cisco Calling Plan og Cloud Connect for Webex Calling er skybaserte alternativer for PSTN-tilgang for Webex Calling-endepunkter. PSTN-tilgang tilrettelegges av en PSTN-leverandør i skyen og krever ikke lokalt utstyr.
Webex-appen	Klientapplikasjon som kjører på skrivebords-OS (Windows, Mac) eller mobil-OS (Android, iOS) og er registrert direkte på Webex Calling-plattformen for ringefunksjonalitet.

Forberede

Forretningsmessige og tekniske krav

Hvorfor det er viktig å samle inn krav:

Forretningskrav

Tekniske krav

Nettverksberedskap og krav

Konfigurer skytilkoblet UC

Vurdering av det nåværende miljøet

Lisensiering

Locations/Sites

Eksisterende inventar devices/clients

Bekreft enhetens kvalifisering

Brukere

PSTN-tilkobling

Funksjoner & funksjonsbruk

Cisco-integrasjoner: Unity Connection UCCX UCCE

Samtaleopptak

Tredjepartsintegrasjoner

Forretningsmessige og tekniske krav

Når du planlegger en migrering fra til , er det avgjørende å samle grundig inn både tekniske og forretningsmessige krav i planleggingsfasen. Dette trinnet sikrer at migreringen er i samsvar med organisasjonens driftsmål og tekniske kapasiteter, og minimerer risikoer og avbrudd.

Hvorfor det er viktig å samle inn krav:

Samsvarer forretningsmål: Å forstå forretningsbehov bidrar til å skreddersy migreringen for å støtte viktige arbeidsflyter, brukeropplevelse og vekstplaner.

Sikrer teknisk kompatibilitet: Å identifisere tekniske krav tidlig forhindrer integrasjonsproblemer med eksisterende infrastruktur, nettverk og endepunkter.

Forenkler ressursplanlegging: Tydelige krav bidrar til å estimere tidslinjer, kostnader og nødvendige ressurser nøyaktig.

Reduserer risikoer: Tidlig oppdagelse av potensielle utfordringer muliggjør proaktive løsninger, noe som reduserer nedetid og avbrudd i tjenesten.

Forretningskrav

Typiske forretningskrav inkluderer:

Antall brukere og steder som skal migreres

Ønskede funksjoner og tjenester (f.eks. samtaleruting, talepost, konferanser, automatiske svarere, samtalekøer)

Samsvars- og sikkerhetspolicyer

Budsjettbegrensninger og kostnadsforventninger

Brukeropplæring og støttebehov

Migreringstidslinje og hensyn til forretningskontinuitet.

Å samle inn ønskede funksjoner og tjenester er et kritisk trinn for å sikre at det nye systemet oppfyller forretningsbehovene. Når man samler inn disse kravene, er det viktig å ikke bare vurdere hva som er konfigurert for øyeblikket, men også prøve å samle inn de faktiske kravene fra forretningsenhetene som skal bruke systemet. Ellers er det en risiko for at planen er basert på ikke-aktuelle forutsetninger. Sørg for å evaluere tilleggs- eller forbedrede funksjoner som er tilgjengelige i som kanskje ikke finnes i , for eksempel skybaserte anrop, avanserte samtalekøer og . Dette bidrar til å utnytte alle fordelene med skyplattformen.

Når man evaluerer den nåværende konfigurasjonen i , er det viktig å være klar over at ikke alle eksisterende innstillinger kanskje fortsatt er nødvendige på grunn av utviklende krav gjennom hele systemets livssyklus. Fokuset bør være på å identifisere og beholde kun de konfigurasjonene som er i samsvar med nåværende og fremtidige behov for utplasseringen.

Fokuser mer på hva du trenger enn hva du har.

Samsvars- og sikkerhetspolicyer er kritiske hensyn under migreringen fra til Webex Calling for å sikre at det nye skybaserte kommunikasjonssystemet overholder juridiske, regulatoriske og organisatoriske standarder.

Overholdelse av regelverk: Organisasjoner må bekrefte at de oppfyller bransjespesifikke forskrifter som GDPR, HIPAA eller SOX, som tar for seg krav til personvern, oppbevaring og håndtering av data, samt landsspesifikke mandater knyttet til datalagring, omgåelse av bompenger og medielokalitet.

Datasikkerhet: Sørge for at tale- og signaldata krypteres både under overføring og i ro for å beskytte mot avlytting eller uautorisert tilgang.

Tilgangskontroller: Definere og håndheve brukerautentisering, autorisasjon og rollebasert tilgang for å forhindre uautorisert bruk av kommunikasjonsressurser.

Revisjon og overvåking: Implementering av loggings- og overvåkingsfunksjoner for å spore tilgang og bruk for samsvarsrevisjoner og undersøkelser av sikkerhetshendelser.

Tilpasning av retningslinjer: Samsvare migreringen med eksisterende sikkerhetspolicyer i bedriften, inkludert endepunktsikkerhet, nettverkssegmentering og hendelsesresponsplaner.

Leverandørsikkerhetsgaranti: Evaluering av Ciscos sikkerhetssertifiseringer og samsvarsattesteringer for å sikre pålitelighet.

Å ta hensyn til disse samsvars- og sikkerhetsreglene i planleggingsfasen bidrar til å redusere risikoer, unngå juridiske sanksjoner og opprettholde integriteten og konfidensialiteten til kommunikasjonen gjennom og etter migreringen.

Brukeropplæring og støttebehov er viktige komponenter under migreringen fra til for å sikre en smidig overgang og brukeradopsjon. Viktige hensyn inkluderer:

Treningsprogrammer: Utvikle skreddersydde opplæringsøkter for ulike brukergrupper (sluttbrukere, administratorer, brukerstøttepersonell) for å gjøre dem kjent med funksjoner, brukergrensesnitt og nye arbeidsflyter.

Dokumentasjon: Tilby tydelige og tilgjengelige brukerhåndbøker, vanlige spørsmål og hurtigreferansemateriell, inkludert Nyheter og forskjeller ressurser og trinnvise Før- og etterveiledninger (i video- eller hurtigveiledningsformat), for å støtte brukerne når de tilpasser seg den oppdaterte opplevelsen etter migreringen.

Endringsledelse: Kommuniser endringer proaktivt for å håndtere brukerforventningene og redusere motstand.

Støttestruktur: Opprett et dedikert støtteteam eller en eskaleringsprosess for å håndtere brukerproblemer raskt under og etter migreringen.

Videreutdanning: Planlegg kontinuerlige opplæringsoppdateringer etter hvert som nye funksjoner eller oppdateringer utgis i .

Tilbakemeldingsmekanismer: Implementer kanaler for brukere til å rapportere problemer og gi tilbakemeldinger for å forbedre opplærings- og støtteprosesser.

Å imøtekomme disse opplærings- og støttebehovene i planleggingsfasen bidrar til å minimere forstyrrelser, øke brukertilliten og maksimere fordelene ved å migrere til .

Tekniske krav

Flere viktige tekniske krav må samles inn og dokumenteres for en vellykket migrering fra til , inkludert detaljer for:

Nettverksberedskap og båndbreddekapasitet

En omfattende nettverksvurdering er avgjørende for å sikre at den eksisterende infrastrukturen din kan støtte det nye Webex Calling-miljøet. Dette inkluderer:

Båndbreddeanalyse: Evaluering av nåværende og anslått båndbreddebruk for å håndtere tale-, video- og datatrafikk uten overbelastning.

Tjenestekvalitet (QoS): Implementering av QoS-policyer for å prioritere taletrafikk og minimere latens, jitter og pakketap.

WAN- og internetttilkobling: Verifisering av at WAN-koblinger og internettforbindelser oppfyller kravene for skybaserte anrop, inkludert redundans- og failover-muligheter.

Brannmur og NAT-konfigurasjon: Sørg for at brannmur- og NAT-innstillinger tillater nødvendig signalering og medietrafikk for .

Integrasjon med eksisterende system

Sømløs integrasjon med eksisterende forretningssystemer er avgjørende for brukeropplevelse og kontinuitet i arbeidsflyten:

Katalogtjenester: Vurderer integrasjon med en bedriftskatalog for automatisert brukerklargjøring og autentisering.

CRM- og forretningsapplikasjoner: Identifisere integrasjonspunkter med systemer for kundeforholdsstyring og andre forretningskritiske applikasjoner.

Samarbeid mellom eldre PBX-systemer: Planlegging for sameksistens eller faseinndelte migreringsstrategier hvis noen eldre telefonisystemer vil bli værende under overgangen.

Endepunktkompatibilitet og klargjøring

Alle endepunkter, inkludert bordtelefoner, programvaretelefoner og mobile enheter, bør evalueres for kompatibilitet:

Enhetsstøtte: Bekrefte at eksisterende IP-telefoner og -enheter støttes av, eller identifisere nødvendige erstatninger.

Provisjoneringsprosesser: Etablering av automatiserte eller strømlinjeformede provisjoneringsmetoder for effektiv onboarding av endepunkter.

Fastvare- og programvareoppdateringer: Planlegging av nødvendige oppdateringer for å sikre interoperabilitet og sikkerhet.

Sikkerhetskonfigurasjoner og krypteringsstandarder

Sikkerhet er avgjørende i skykommunikasjon:

Kryptering: Håndheving av ende-til-ende-kryptering for signalering og mediestrømmer, i tråd med beste praksis for sikkerhet hos Cisco.

Autentisering og tilgangskontroll: Implementering av sikre autentiseringsmekanismer (som SSO, flerfaktorautentisering) og detaljerte brukertilgangskontroller.

Samsvar: Sørge for at løsningen oppfyller relevante regulatoriske og bransjestandarder (for eksempel GDPR, HIPAA).

Sikkerhetsovervåking: Integrering med SIEM-verktøy og oppsett av varsler for potensielle sikkerhetshendelser.

Tabell 1. Eksempelvurdering
Behov Viktige hensyn

Nettverksberedskap og båndbredde Båndbredde, QoS, WAN/Internet, Firewall/NAT

Integrasjon med eksisterende systemer Katalog, CRM, PBX, Email/Calendar

Endepunktkompatibilitet og klargjøring Enhetsstøtte, klargjøring, fastvareoppdateringer

Sikkerhetskonfigurasjoner og kryptering Kryptering, autentisering, samsvar, sikkerhetsovervåking

Brukeropplæring og endringsledelse Opplæringsprogrammer, dokumentasjon, endringskommunikasjon

Nummerportabilitet og oppringingsplan Tall migration/porting, oversettelse av oppringingsplan

Tredjepartsintegrasjoner Personsøker, kontaktsenter, faks, analoge enheter

Nettverksberedskap og krav

Nettverksberedskap er avgjørende for en vellykket migrering til enhver skybasert ringeløsning som . Dårlig nettverksplanlegging kan føre til dårligere samtalekvalitet, tapte samtaler og misfornøyde brukere. Kunder må gjennomføre en nettverksvurdering før de migrerer til . Det anbefales å bekrefte tilgjengeligheten av nettverksbåndbredde for forventet samtalevolum, sørge for at kravene til tjenestekvalitet (QoS) er oppfylt, og forstå de ulike portene som må åpnes i kantbrannmuren(e).

Pålitelig nettverkstilkobling med tilstrekkelig tjenestekvalitet (båndbredde, pakketap, RTT) er et grunnleggende krav for å sikre best mulig brukeropplevelse fra ende til ende for alle tale- og videokompatible endepunkter, klienter og applikasjoner som bruker .

Kunder og partnere har tilgang til tilkoblingsalternativer utover Over-the-top (OTT) Internett som kan optimalisere tilkoblingen til å inkludere Webex Edge Connect. Hvis du vil ha mer informasjon om designdetaljer for Webex Edge Connect, kan du se Cisco Preferred Architecture for Webex Edge Connect for Webex Meetings, Calling Multi-Tenant og Dedicated Instance.

Kunder kan bruke CScan for nettverksvurdering, som gir informasjon om kundens nettverkskvalitet, hvor mange samtaler som kan opprettes, latens og så videre. Hvis du vil ha mer informasjon om CScan-verktøyet, kan du se Bruk CScan til å teste nettverkskvaliteten for Webex Calling.

For å sikre at nettverket er klart for migrering til , bør du vurdere følgende sjekkliste:

Båndbreddeplanlegging

Beregn samtidige anrop per lokasjon for å sikre at du har nok oppstrøms og nedstrøms båndbredde, og inkluder kapasitet for annen forretningskritisk trafikk og fremtidig vekst.

Tabellen Båndbreddeberegninger for Webex Calling-anropstype viser anropstypene som er tilgjengelige med en distribusjon, sammen med kodeken og maksimal båndbredde som kreves for hver anropstype. Som vist i tabellen Webex Calling båndbreddeberegninger for samtaletype kan nødvendig lydanropsbåndbredde for hver samtaletype beregnes ved hjelp av følgende generelle formel:

Antall forventede samtidige anrop * Båndbredde per samtale basert på kodek = Nødvendig nettverksgjennomstrømning.
Tabell 2. Båndbreddeberegninger for Webex Calling-samtaletype
Anropstyper Kodek - båndbredde Båndbreddeberegninger
/ Bordtelefon -> OPUS – 70 kbps Antall samtidige samtaler * 70 kbps = Nødvendig nettverksgjennomstrømning
/ Bordtelefon -> Bordtelefon OPUS – 70 kbps Antall samtidige samtaler * 70 kbps = Nødvendig nettverksgjennomstrømning
/ Bordtelefon -> PSTN via LGW G.711 – 80 kbps Antall samtidige samtaler * 80 kbps = Nødvendig nettverksgjennomstrømning
/ Bordtelefon -> PSTN via Cloud PSTN (f.eks. Cisco-abonnement) G.711 – 80 kbps Antall samtidige samtaler * 80 kbps = Nødvendig nettverksgjennomstrømning
/ Bordtelefon -> Bedrift via LGW G.722 – 80 kbps Antall samtidige samtaler * 80 kbps = Nødvendig nettverksgjennomstrømning
/ Bordtelefon -> telefonsvarer OPUS – 70 kbps Antall samtidige samtaler * 70 kbps = Nødvendig nettverksgjennomstrømning

Ved å summere den samtidig nødvendige nettverksgjennomstrømningen per samtaletype, kan det totale potensielle båndbreddekravet for et bestemt sted bestemmes.

Alle anropsben er alltid forankret på tilgangs-SBC-ene. For å bestemme den nødvendige internettbåndbredden for et gitt sted, må ikke bare samtaler mellom lokasjoner vurderes, men også samtaler innenfor lokasjonen og samtaler til og fra en lokal gateway på det stedet. For eksempel vil en intern samtale mellom to MPP-telefoner trenge opptil 2 x 70 kbps full dupleks på stedets internettilgang.

Tabellen Eksempler på båndbreddeberegning for Webex-anrop viser et eksempel på en komplett båndbreddeberegningsøvelse, forutsatt at alle enhetene er på samme sted.
Tabell 3. Eksempler på beregning av båndbredde for Webex-anrop
Anropstyper Antall samtidige samtaler Total båndbredde
Webex-appen / Bordtelefon → Webex-app 15 2 * 15 * 70 kbps = 2100 kbps
Webex-appen / Bordtelefon → Bordtelefon 15 2 * 15 * 70 kbps = 2100 kbps
Webex-appen / Bordtelefon → PSTN via LGW 50 2 * 50 * 80 kbps = 8000 kbps
Webex-appen / Bordtelefon → PSTN via Cloud Connect for Webex Calling 0 0 * 80 kbps
Webex-appen / Bordtelefon → Bedrift via LGW 15 2 * 15 * 80 kbps = 2400 kbps
Webex-appen / Bordtelefon → Webex Calling-talepost 5 5 * 70 kbps = 350 kbps
Totalt antall samtaler / Båndbredde 100 samtaler 14 950 kbps / 14,95 Mbps

Alle båndbreddeverdier i tabellene ovenfor refererer til IP-båndbredde. Koblingsbåndbredden er høyere avhengig av WAN-innkapslinger.

Båndbredden i tabellene ovenfor er for lydanrop. For båndbredde for videosamtaler, Webex-appen og MPP 8845/65 Telefoner støtter H.264-video med maksimal oppløsning på 720p og en maksimal båndbredde på 1500 kbps per samtale. Imidlertid vil mengden båndbredde som forbrukes på et hvilket som helst tidspunkt under samtalen variere basert på den variable bithastigheten som er iboende i videokommunikasjon.

Tjenestekvalitet (QoS)

Implementer QoS-policyer i ditt lokale miljø for å prioritere sanntidstrafikk, og sørg for at QoS opprettholdes på tvers av svitsjer, rutere og brannmurer.

Mål for latens, jitter og pakketap

Følgende terskler anbefales for optimal talekvalitet når samtaler går over internett (Over-the-Top, OTT):

Latens - mindre enn 100 ms enveis

Jitter - mindre enn 10 ms

Pakketap – 0,5 % eller mindre.

Brannmur og NAT

Sørg for at brannmuren er konfigurert til å tillate trafikk som oppført i artikkelen som er tilgjengelig på Portreferanseinformasjon for Webex Calling. I tillegg bør du tillate tilgang til domener og IP-områder som er oppført i samme veiledning, og unngå SIP ALG, da det forstyrrer SIP-signalering. Medietrafikk gjennom proxyer bør unngås.

DNS og NTP

Sørg for riktig DNS-oppløsning for domener og pålitelige NTP-servere for å synkronisere enhetsklokker for TLS-sertifikatverifisering og logging.

Failover-planlegging

Vurder eksisterende leverandørdatatilkoblinger (MPLS, SD-WAN osv.) og planlegg generelt for direkte internettilgang på hvert sted i implementeringen din. Planlegg for redundante internettkoblinger der høy tilgjengelighet er nødvendig. Fordi du skal bruke skybaserte tjenester, er pålitelig internettforbindelse med tilstrekkelig båndbredde et grunnleggende krav. Du bør vurdere å gjøre denne overgangen hvis internettforbindelsen(e) til organisasjonens lokasjoner generelt ikke er pålitelig(e) med lav latens og tilstrekkelig opp- og nedstrøms gjennomstrømning.

Overlevelsesevne på stedet

Nettstedets overlevelsesevne sikrer at bedriften din alltid er tilgjengelig, selv om nettverksforbindelsen brytes. Site Survivability bruker en gateway i ditt lokale nettverk for å tilby en reservetjeneste for anrop til endepunkter på stedet i situasjoner der nettverksforbindelsen brytes. Vurder stedets overlevelsesevne med en lokal overlevelsesgateway (SGW) hvis forretningskrav krever kontinuerlig oppringing i tilfelle nettverksbrudd. Hvis du vil ha mer informasjon om kontroll av nettstedets overlevelsesevne, kan du se Nettstedets overlevelsesevne for Webex Calling.

Konfigurer skytilkoblet UC

Cloud Connected UC (CCUC) er en skybasert administrasjons- og analyseløsning som er utviklet for å gi sentralisert oversikt, administrasjon og innsikt for distribusjoner både lokalt (som Unified CM) og i skyen (). Den fungerer som en bro mellom tradisjonelle lokale miljøer og Ciscos skytjenester, og støtter organisasjoner gjennom hele migreringsreisen fra til .

Under overgangen til spiller CCUC en viktig rolle i å effektivisere migreringsprosessen ved å legge til rette for innsamling av omfattende data fra den eksisterende Unified Communications-distribusjonen. CCUC bistår med viktige overgangsoppgaver som migrering av enheter, funksjoner og brukerkontakter, samt automatisering av fastvareoppdateringer for støttede IP-telefoner. Ved å tilby sentralisert oversikt og administrasjon, bidrar CCUC til en smidigere og mer effektiv migreringsopplevelse.

Cisco anbefaler på det sterkeste at CCUC implementeres og implementeres tidlig i overgangsprosjektet, ideelt sett før eller under forberedelsesfasen. Dette vil gi deg innsikten og funksjonene som trengs for å grundig vurdere, kartlegge og planlegge påfølgende migreringsaktiviteter, og for å starte reisen mot fremtidige hybridfunksjoner.

Vurdering av det nåværende miljøet

En viktig aktivitet i planleggingen av migreringen er å vurdere det nåværende lokale miljøet og distribusjonen. Dette gir innsikt i hvilke potensielle endringer som kan være nødvendige for en vellykket overgang til . Det lar deg også vurdere nøkkelelementene i plattformen i sammenligning med eksisterende lokale distribusjon. Du kan bruke denne informasjonen til å identifisere hvilke spesifikke oppgaver som kreves for overgangen, og hvilke endringer du ønsker å gjøre for å oppfylle dine forretningsmessige og tekniske krav og brukstilfeller.

Følgende aspekter er viktige å gjennomgå som en del av dette arbeidet.

Lisensiering

Det er viktig å forstå den nåværende lisensstrukturen for den eksisterende distribusjonen når man forbereder seg på å migrere til . Utfør en lisensvurdering av følgende områder av din eksisterende lokale Cisco-løsning.

Plattform

Evnen til å fullt ut formulere hva som for øyeblikket er lisensiert på kjerneplattformen din vil være avgjørende når du samarbeider med kontoteamet eller partneren din for å bestemme den beste veien til fleksibel lisensiering. er lisensiert ved hjelp av fleksibel lisensiering. Hvis du vil ha mer informasjon om fleksibel lisensering, kan du se Cisco Collaboration Flex Plan.

Brukere og enheter

Identifiser hvilken lisenskategori dine eksisterende brukere og enheter krever. Dette vil bli brukt til å bestemme hvilken type lisens som kreves for brukerne og enhetene. tilbyr flere lisenstyper, inkludert profesjonelle og standardlisenser for brukere og profesjonelle og fellesområdelisenser for arbeidsområder. For mer informasjon om enhetslisenser, se databladet som er tilgjengelig på Enhetslisensiering.

Lokal gateway

Hvis Cisco Unified Border Element (CUBE) er nødvendig for PSTN-tilgang for denne overgangen, må CUBE-lisensiering også vurderes. Hensyn knyttet til CUBE-lisensiering dekkes senere i dette dokumentet.

Locations/Sites

Antall og typer steder (store sentrale, regionale, filialer osv.) innenfor din eksisterende implementering bør vurderes når du planlegger denne overgangen. En full forståelse av de eksisterende utplasseringsstedene vil hjelpe til med strategisk planlegging for en vellykket overgang, spesielt når det gjelder å bestemme hvilke steder som skal migreres og i hvilken rekkefølge. Det vil være avgjørende å forstå kravene til oppringingsplaner (nummerering, oppringingsvaner, restriksjonsklasser osv.), nettverkstilkobling og båndbredde (Internett, WAN, LAN) og PSTN-tilgang (lokal eller sentralisert, IP eller TDM) for hvert sted i detalj når man tar migreringsbeslutninger. Hvis du vil ha mer informasjon om vanlige distribusjonsmodeller og viktige hensyn, kan du se informasjonen om samarbeidsdistribusjonsmodeller som er tilgjengelig i Samarbeids-SRND.

En annen viktig faktor å vurdere når man går over til, er tilgjengeligheten av plassering. har forskjellige funksjoner, abonnementer og enheter som er tilgjengelige avhengig av hvor distribusjonen din befinner seg. Hvis du vil ha mer informasjon om geografisk tilgjengelighet, kan du se Hvor er Webex tilgjengelig?.

Til slutt er det viktig å forstå hvilken innvirkning overgangen til vil ha på andre samarbeidstjenester. Basert på målet med dette dokumentet er den generelle antagelsen at dersom eksisterende samarbeidstjenester utenfor den anropende arbeidsmengden skal opprettholdes, forventes det en overgang til fase 1-hybriddistribusjonen som er nevnt ovenfor. Eksempler på samarbeidstjenester som kan kreve hybrid distribusjon inkluderer lokale kontaktsentre som ennå ikke er migrert til Webex kontaktsenter og tette integrasjoner i systemer som personsøkersystemer og fakturering. Hvis du vil ha mer informasjon om overføring av ytterligere samarbeidsarbeidsmengder og -tjenester, kan du se Samarbeidsoverganger.

Eksisterende inventar devices/clients

Før overgangen starter, er det viktig å lage en oversikt over eksisterende maskinvare- og programvareendepunkter. Har en komplett liste over enheter types/models, Maskinvareversjoner, typer og mengder av programvareklienters operativsystemer vil sikre at du kan planlegge overføring av enhetene på en tilstrekkelig måte og redusere virkningen for de enhetene som ikke kan migreres til skyanrop. Inventaret bør brukes til å bestemme hvilke enheter som skal overføres og hvilke enheter som skal erstattes før overgangen.

Bordtelefoner

For bordtelefoner med lyd og video støttes bare bordtelefonene i 6800-, 7800-, 8800- og 9800-serien. Dette er et delsett av Cisco IP-telefoner som støttes med . Det finnes noen modeller og versjoner av 6800-, 7800- og 8800-telefonene som ikke kan brukes med . Hvis du vil ha mer informasjon om hvilke modeller og maskinvareversjoner som støttes, kan du se Støttede enheter for Webex Calling.

Cisco 6800-serien av IP-telefoner kan ikke oppgraderes fra Enterprise-fastvare til Multiplatform (MPP)-fastvare, som er nødvendig for . Derfor må alle 6800-telefoner som er registrert for å kjøre bedriftsfirmware, erstattes med en 6800 MPP-modell eller en annen støttet telefonmodell.

Cisco 7800- og 8800-serien av IP-telefoner må oppgraderes til fastvaren for multiplattformtelefoner (MPP) før overgang og registrering av dem. For å finne ut hvilke 7800- og 8800-modeller og maskinvareversjoner som støtter MPP-fastvaren, se Konverter Cisco 7800- og 8800-serien IP-telefoner mellom Enterprise- og MPP-fastvare.

8845, 8865 og 8865NR har nådd slutten av salget og anbefales ikke å migrere til .

Eldre versjoner av telefonene i 8800-serien (8811, 8841, 8851, 8851NR, 8861) anbefales ikke å bruke med Webex Calling. Telefoner med maskinvareversjoner VID 14 eller tidligere vil registreres med, men kan oppleve noen ytelsesproblemer på grunn av maskinvaren.

Bordtelefonene i 9800-serien kjører PhoneOS, som støtter både og registrering. Derfor kan disse telefonene overføres til uten en fastvareoppgradering.

Alle andre IP-telefoner må byttes ut med telefoner i 6800-, 7800-, 8800- eller 9800-serien som støttes av Webex Calling. Hvis du vil ha mer informasjon om støttede IP- og bordtelefoner med [], kan du se artikkelen på Støttede enheter for Webex Calling.

Videoendepunkter

Personlige og rombaserte videoendepunkter, inkludert Cisco Board-serien, Room-serien og Desk-serien, kan innebygd SIP-registreres til . Noen av disse endepunktene som trenger å lage lyd and/or PSTN-anrop krever en ringelisens:

Delte enheter i konferanserom, møterom osv. krever enten en Professional Workspace- eller Workspace-lisens.

En sluttbrukers personlige enhet krever en profesjonell eller standard lisens.

Bestem hvor mange videoendepunkter som er registrert til og brukes til å foreta lydanrop. Det er mulig at noen av videoendepunktene bare brukes til å bli med i møter eller foreta SIP-videosamtaler. I begge tilfeller må endepunktene fortsatt migreres til før serverne tas ut av drift, men dette vil bidra til å bestemme hvor mange av dem som trenger lisenser for å fortsette å ringe.

Når videoenheter flyttes fra registrering til , vil URI-en for disse endepunktene endres, ettersom de nå er skyregistrert.

Telefonmodellene 8845, 8865 og 8875 er personlige videotelefoner som støttes med .

Myke klienter

er den eneste mykklienten som støttes av , i motsetning til Unified CM som støtter både Webex-appen og Jabber, og er den nye standard mykklienten for sluttbrukere.

Avhengig av distribusjonsmodusen(e) som er implementert for Jabber (kun direktemeldinger, kun telefon, and/or fulle UC-moduser), må du kanskje også vurdere overgangen til Meldingsfunksjonen and/or Møtearbeidsbelastninger fra Jabber til . Den kan distribueres i telefonmodus hvis den skal brukes som en klient for kun anrop, eller den kan distribueres som den komplette Webex Suite hvis andre arbeidsbelastninger, f.eks. Webex Messaging, brukes. and/or Webex Meetings blir overført til appen med anrop.

Det forbedrer sluttbrukeropplevelsen ved å tilby AI-funksjoner som audio/video intelligens, samtaletranskripsjon og annet. For mer informasjon, se https://www.webex.com/all-new-webex.

Før du flytter brukere til deg, må du overføre Jabber-klientene deres til . Du har to alternativer for å fullføre denne overgangen.

Før du overfører dem til

Når du overfører dem til .

For å forenkle den første overgangen til , anbefales det å bruke alternativ 1 og flytte brukere til med kallet først. Dette gir brukerne tid til å bli kjent med den nye applikasjonen mens de fortsatt bruker den eksisterende lokale anropsplattformen. Når du er klar til å flytte brukere til , konfigurerer du dem til å registrere seg på skyanropsplattformen.

For mer informasjon om disse to alternativene, se Migreringsreise - ett eller to trinn?.

For en fullstendig liste over støttede enheter for , se Støttede enheter for Webex Calling.

Bekreft enhetens kvalifisering

Som nevnt tidligere, støtter den et delsett av Cisco IP-telefoner og krever en annen fastvaretype for telefonene i 7800- og 8800-serien. Unified CM-telefoner kjører Enterprise-fastvaren, mens telefoner kjører Multiplatform Phone (MPP)-fastvaren. Det anbefales å bekrefte hvilke registrerte telefoner som er kvalifisert for oppgradering til MPP-fastvaren i forberedelsesfasen. Dette gir deg tid til å erstatte ikke-kvalifiserte telefoner med en av de støttede telefonmodellene eller til å identifisere en alternativ plan, for eksempel å flytte en bruker til kun Webex-appen.

For å hjelpe med å avgjøre om telefonene er kvalifisert, har Control Hub et innebygd verktøy kalt Migrer telefonen din til Webex Calling. Når du bruker dette verktøyet til å sjekke om enheten er kvalifisert, velger du migreringsalternativet Generer kun enhetslisens.

Verktøyalternativ for kontrollhub for å bekrefte at Unified CM-telefoner er kvalifisert for Webex Calling

Dette alternativet lar deg laste opp en CSV-fil som inneholder telefonene, slik at du kan sjekke om hver telefon er kvalifisert. Ved å velge dette migreringsalternativet legges ikke telefonene til, siden du fortsatt er i forberedelsesfasen og ikke er klar til å gjøre dette ennå. Hvis du vil ha mer informasjon, kan du se Migrer telefonen din til Webex Calling.

Det er mulig at noen av telefonene kommer tilbake med en Ukjent kvalifisering. Dette skyldes vanligvis at den ikke kan validere informasjon om telefonen i backend-systemet. For telefoner som har statusen Ukjent har du to alternativer for å bekrefte om de er kvalifisert for oppgradering til MPP-fastvaren.

Sjekk hver telefon manuelt og bekreft modell og maskinvareversjon (PID VID)

7800/8800 telefonetikett med informasjon om modell og maskinvareversjon

Bruk Cisco IP-telefonklargjøringsverktøyet

Last ned verktøyet fra https://github.com/joemar2/mpp_readiness_check.

Dette verktøyet er ikke et offisielt Cisco-verktøy, og det støttes heller ikke av TAC. Den har best-effort-støtte, men er gratis å bruke.

Dette verktøyet må kjøres på en maskin som er lokal og har tilgang til serverne og IP-telefonene. Den har et alternativ for å aktivere nettilgang på IP-telefonene, noe som anbefales og er nødvendig for å få best mulig resultat. Derfor bør den brukes utenom arbeidstid for å unngå forstyrrelser for sluttbrukerne. Verktøyet gir en rapport som viser hvilke av telefonene i 7800- og 8800-serien som er kvalifisert for oppgradering til MPP-fastvaren. Fordi den har direkte tilgang til telefonen, kan den bekrefte Ukjente enheter som ble rapportert fra Control Hub-verktøyet.

Rapport om verktøyet for klargjøring av Cisco IP-telefoner

Brukere

Et av de viktigste forberedelsestrinnene for å sikre en vellykket migrering er riktig brukerklargjøring. Du må planlegge skikkelig for alle brukere, selv om du gjennomfører en faseinndelt migrering. Brukere må være klargjort for ett av følgende:

Distribuere med Calling

Distribuere med

Konfigurere tjenester for en bruker

For å gjøre brukere søkbare i katalogen (klikk for å ringe, brukerkontaktinformasjon, søk i telefonkatalogen).

Det anbefales at du klargjør alle brukere før eller ved starten av prosjektet. Dette inkluderer brukere som fortsatt bruker Unified CM for sin ringeplattform som er uavhengig av ringeenheten deres (IP-telefon, Jabber, ). Etter hvert som brukere blir migrert til (and/or den ) du vil oppdatere lisensene deres for å aktivere tjenestene de trenger. Ved å klargjøre alle bedriftskallende brukere før overgangen starter, kan en bruker som har gått over til eller til søke i katalogen etter en bedriftskallende bruker som fortsatt er på Jabber. and/or på. Dette sikrer at brukere som har gått over til å bruke katalogoppslaget kan finne kontaktinformasjonen til andre brukere og ringe dem.

Figuren katalogsøk viser et eksempel på en bruker som søker etter en annen bruker. Søkeresultatene viser brukerens kontaktinformasjon og kan være for en bruker som fortsatt er på Jabber og/eller for en bruker som har gått over til and/or .

Søk i Webex-appens katalog

Bestem deretter hvilke av de eksisterende lokale anropende brukerne som skal overføres til . Hvis alle eller et stort antall brukere skal overføres, anbefales det å flytte brukerne i grupper for å sikre at prosjektteamet, IT-ansatte og støttepersonell kan håndtere overgangen og eventuelle problemer som måtte oppstå. Du bør også sette av litt tid til å gi innledende informasjon og opplæring for å forberede brukerne på denne overgangen. Gruppering av brukeroverganger kan gjøres basert på en rekke kriterier, inkludert plasseringen eller nettstedet brukerne er tilordnet, brukernes avdelinger eller til og med brukertyper (kunnskapsarbeidere, ledere, mobile arbeidere og så videre).

Hvis brukerne i utrullingen for eksempel er fordelt på tre hovedsteder, New York (NYC), San Francisco (SFC) og Research Triangle Park (RTP), kan en brukerovergangsplan se ut som planen som er skissert i tabellen Brukerovergangsplan etter sted.
Tabell 4. Brukerovergangsplan etter nettsted
Brukernettsted / sted Informasjon og opplæring før overgang Overgangsperiode Støtte etter overgang
NYC (1525 brukere) Uken 1. april 15. april – 27. april Uken som startet 29. april
SFO (1600 brukere) Uken 6. mai 20. mai – 31. mai Uken 3. juni
RTP (1 275 brukere) Uken 3. juni 17. juni – 28. juni Uken 1. juli

En annen viktig faktor er å overføre brukere som har avhengigheter mellom hverandre, sammen. Dette kan inkludere, men er ikke begrenset til, følgende:

BLF-overvåking

Samme jakt pilot/group

Del linjer

Del av samme samtalehentingsgruppe

Bruker de samme parkeringsnumrene for samtaler

Intercom

Admin/Exec.

Du kan se gjennom konfigurasjonen (GUI eller eksport) eller bruke verktøyet Migration Insights for å identifisere brukergruppene med disse avhengighetene.

PSTN-tilkobling

kan få tilgang til PSTN på tre måter: Cisco-ringeabonnementer, Cloud Connect for (tidligere Cloud Connected PSTN) og lokal PSTN (lokal gateway). Imidlertid kan én enkelt plassering som definert i bare tilordnes til ett PSTN-alternativ.

Lokalt PSTN med en lokal gateway (LGW) er en viktig del av overgangsstrategien. Den gir tilkobling mellom den lokale distribusjonen and/or PSTN og plattformen støtter både Cisco og sertifiserte tredjeparts sessionsgrensekontrollere (SBC) som kan brukes som lokal gateway. For den nyeste listen over støttede SBC-er, se Liste over støttede SBC-er.

støtter opptil 250 samtidige anrop fra en enkelt lokal gateway som er registreringsbasert og mer enn 250 samtidige anrop fra en enkelt lokal gateway som er sertifikatbasert. Sertifikatbaserte lokale gatewayer kan støtte opptil 6500 samtidige anrop, men dette er basert på typen tilkobling den lokale gatewayen har til (Over-the-Top vs. interconnect-peering) og SBC-modellen den lokale gatewayen er distribuert på. Disse grensene er i hovedsak standardtallgrensen for både lokale gateway-baserte PSTN-anrop og anrop mellom steder mellom og endepunkter. Hvis du vil ha mer informasjon, kan du se Kom i gang med lokal gateway.

Alle anrop som overskrider denne grensen blir avvist med en 403 Forbudt. Kommandoen show call active voice kan kjøres på den lokale gatewayen når som helst for å bestemme det totale antallet aktive samtaler.

Dårlige nettverksforhold mellom en lokal gateway og tilgangs-SBC-en kan begrense ytelsen til signalforbindelsen, noe som fører til en enda lavere grense for samtidige anrop. Enveisforsinkelsen mellom den lokale gatewayen og datasenteret bør ikke overstige 100 ms, og jitteren bør være mindre enn 10 ms, mens pakketapet er mindre enn 0,5 ms. %.

Funksjoner & funksjonsbruk

Når man vurderer det nåværende miljøet, er det viktig å identifisere og gjennomgå hvilke funksjoner som er konfigurert. I tillegg er det viktig å forstå bruken av funksjonene, slik at du kan (re)definere forretnings- og tekniske krav for utrullingen.

For å finne ut hvilke funksjoner som er konfigurert, analyser konfigurasjonen. Dette er alle statiske data som angis når en funksjon eller innstilling konfigureres på systemet. Følgende alternativer kan brukes til å fullføre denne analysen:

Gjennomgå konfigurasjonen i administratorgrensesnittet

konfigurasjonseksport -- masseeksport eller AXL

Verktøy for migreringsinnsikt (anbefales)

Cisco-verktøy fra tredjepartspartnere (anbefales).

For å analysere funksjonsutnyttelse effektivt er det viktig å undersøke dynamiske systemdata som utnyttelse, registreringer og samtaleaktivitet. Ulike analyseverktøy og dashbord gir innsikt i disse målingene, noe som muliggjør en omfattende forståelse av systemytelse og kapasitet, noe som støtter informert beslutningstaking under migrerings- og optimaliseringsarbeid. Følgende alternativer kan brukes til å fullføre denne typen analyse:

Gjennomgang av rå CDR-poster

Gjennomgang av Unified CM RTMT-data

Migrasjonsinnsiktsverktøy ved bruk av CDR-data

Gjennomgang av skytilkoblet UC-analyse i

Samtalevolum

Registrerte endepunkter

(CAC)-lokasjoner

Utnyttelse av bagasjerommet.

Cisco-verktøy fra tredjepartspartnere.

Cisco anbefaler å starte med Webex Control Hub Migration Insights-verktøyet for denne analysen. Du importerer den eksporterte .TAR-filen og Unified CM CDR-filene (valgfritt, men nødvendig for analyse av funksjonsutnyttelse) til verktøyet. Verktøyet vil generere følgende CSV-baserte rapporter som kan brukes til å starte analysen:

Tabell 5. Rapporter generert fra Unified CM .tar-fil
Rapportnavn
Rapportbeskrivelse
ImportedDataBulk.csv
Alle brukere og enheter fra Unified CM-data
DeviceEligibility.csv
Identifiserer enheter som er kvalifisert for migrering til Webex Calling (IP-telefoner, rom-OS-enheter, ATA-er og tredjepartsenheter)
DevicePoolNumbers.txt
Liste over alle numre i en bestemt enhetspool
HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv
Detaljer om enheter og brukere som skal migreres sammen basert på delte linjer, Hunt Pilot, samtalekø, samtaleparkering og konfigurasjon av samtalehentingsgruppe
HuntGroupMigrationInsight.csv
Detaljert informasjon om tildelte jaktlinjer, linjegrupper og tilknyttede agenter
SharedlineGroupMigrationReport.csv
Oversikt over hvordan telefonnumre (katalognumre) deles mellom brukere

Tabell 6. Rapporter generert fra Unified CM .tar- og CDR.gzip-filer
Rapportnavn
Rapportbeskrivelse
FeatureUsageBasedDeviceEligibilityReport.csv
Informasjon om kvalifisering for enhetsmigrering basert på funksjonsbruk
FeatureUsageWithLastUsageDateReport.csv
Brukstelling for antall ganger jaktpilot(er) og anropskø(er) har blitt anropt, sammen med siste bruksdato.
UserWorkspaceLastUsage.csv
Siste bruksdato for brukere og arbeidsområder for både programvareklienter og harde telefoner
DIDUsageReport.csv
DID-bruk for både tildelte og ikke-tildelte DID-er

Hvis du vil ha mer informasjon om rapportene om migreringsinnsikt, kan du se Migreringsinnsikt.

Hvis du trenger mer informasjon om funksjonene og bruken etter å ha gjennomgått informasjonen i Migration Insights-rapportene, anbefaler Cisco at du vurderer et av Ciscos migreringsverktøy fra tredjepartspartnere. and/or for å gjennomgå konfigurasjonene i det grafiske brukergrensesnittet eller i konfigurasjonseksportdataene.

Cisco-integrasjoner: Unity Connection UCCX UCCE

Talepost er en integrert del av tilbudet og innebygd i løsningen. Kan ikke integreres med en lokalebasert talepostløsning som Unity Connection eller Unity Connection Express. Videre finnes det ingen innebygd måte å migrere eksisterende talepostmeldinger eller hilsener fra Unity-tilkoblingen til den innebygde taleposttjenesten som er tilgjengelig med . Noen av migreringsverktøyene til Ciscos tredjepartspartnere har muligheter til å migrere noen av disse dataene. Hvis du vil ha mer informasjon om talepost for Konfigurer og administrer talepostinnstillinger for en Webex Calling-bruker.

støtter også delte telefonsvarer- og fakspostkasser. Hvis du vil ha mer informasjon, kan du se Administrer en delt talepost og innkommende faksboks for Webex Calling.

har en innebygd automatisk svarfunksjon som er inkludert som en del av kjerneplattformen. Denne funksjonen tillater overføring av Unity Connections samtalebehandlere og automatisk svarfunksjonalitet. Control Hub-verktøyet, Migrer funksjoner fra Unified CM, støtter migrering av Unity Connection-konfigurasjoner til automatiske svarere. Hvis du vil ha mer informasjon om bruk av dette verktøyet, kan du se Migrering av enheter og funksjoner fra Unified CM til Webex Calling.

Samtaleopptak

inkluderer to alternativer for samtaleopptak uten ekstra kostnad.

Webex-samtaleopptak

Dubber Go-opptak (partnertilbud) – en integrasjon mellom og dubber der alt innspilt media lagres sikkert i skyen.

inkluderte opptaksalternativer tabellen fremhever noen viktige funksjoner ved de to alternativene for samtaleopptak som er tilgjengelige uten ekstra kostnad.

Tabell 7. inkluderte opptaksalternativer
Webex Dubber Go

Tilgjengelig for alle brukere Tilgjengelig for alle brukere

Ubegrensede opptak Ubegrensede opptak

1 års oppbevaringsperiode* 30-dagers oppbevaringsperiode

100 GB lagringsplass per organisasjon -

Samsvarsansvarlige kan få tilgang til og administrere samtaleopptak -

API-er for å administrere opptak -

Administratorer kan konfigurere og administrere brukernes tilgang til samtaleopptakene sine
Brukere kan administrere sine egne opptak ved hjelp av brukerhub and/or Webex-appen.
Bare brukere kan få tilgang til og administrere opptakene sine
Fra dubberportalen deres.

Hvis organisasjonen din trenger ytterligere opptaksfunksjoner, som opptak av samtaler i samsvar med regelverket, lengre oppbevaringsperioder, mer lagringsplass eller AI-analyse, and/or administratortilgang, betalte tilbud eller tillegg finnes fra både Cisco og tredjepartsleverandører av opptak. Hvis du vil ha mer informasjon om opptaksleverandører, konfigurasjoner og tilleggspartnertjenester, kan du se Administrer samtaleopptak for Webex Calling.

Tredjepartsintegrasjoner

støtter en rekke^{tredjepartsintegrasjoner}, inkludert, men ikke begrenset til, SBC-er for lokale gatewayer, IP-telefoner, intercom-telefoner, Speaker/Pagers, ATA-er, osv. I tillegg til disse^{tredjepartsenhetene støtter Webex Calling forskjellige^{tredjepartsløsninger for kundestøtte,} analyse , opptak, fakturering osv} . Hvis du^{vil ha mer informasjon om} tredjepartsløsninger , kan du se Webex App Hub.

Tabell 1. Eksempelvurdering
Behov	Viktige hensyn
Nettverksberedskap og båndbredde	Båndbredde, QoS, WAN/Internet, Firewall/NAT
Integrasjon med eksisterende systemer	Katalog, CRM, PBX, Email/Calendar
Endepunktkompatibilitet og klargjøring	Enhetsstøtte, klargjøring, fastvareoppdateringer
Sikkerhetskonfigurasjoner og kryptering	Kryptering, autentisering, samsvar, sikkerhetsovervåking
Brukeropplæring og endringsledelse	Opplæringsprogrammer, dokumentasjon, endringskommunikasjon
Nummerportabilitet og oppringingsplan	Tall migration/porting, oversettelse av oppringingsplan
Tredjepartsintegrasjoner	Personsøker, kontaktsenter, faks, analoge enheter

Tabell 2. Båndbreddeberegninger for Webex Calling-samtaletype
Anropstyper	Kodek - båndbredde	Båndbreddeberegninger
/ Bordtelefon ->	OPUS – 70 kbps	Antall samtidige samtaler * 70 kbps = Nødvendig nettverksgjennomstrømning
/ Bordtelefon -> Bordtelefon	OPUS – 70 kbps	Antall samtidige samtaler * 70 kbps = Nødvendig nettverksgjennomstrømning
/ Bordtelefon -> PSTN via LGW	G.711 – 80 kbps	Antall samtidige samtaler * 80 kbps = Nødvendig nettverksgjennomstrømning
/ Bordtelefon -> PSTN via Cloud PSTN (f.eks. Cisco-abonnement)	G.711 – 80 kbps	Antall samtidige samtaler * 80 kbps = Nødvendig nettverksgjennomstrømning
/ Bordtelefon -> Bedrift via LGW	G.722 – 80 kbps	Antall samtidige samtaler * 80 kbps = Nødvendig nettverksgjennomstrømning
/ Bordtelefon -> telefonsvarer	OPUS – 70 kbps	Antall samtidige samtaler * 70 kbps = Nødvendig nettverksgjennomstrømning

Tabell 3. Eksempler på beregning av båndbredde for Webex-anrop
Anropstyper	Antall samtidige samtaler	Total båndbredde
Webex-appen / Bordtelefon → Webex-app	15	2 * 15 * 70 kbps = 2100 kbps
Webex-appen / Bordtelefon → Bordtelefon	15	2 * 15 * 70 kbps = 2100 kbps
Webex-appen / Bordtelefon → PSTN via LGW	50	2 * 50 * 80 kbps = 8000 kbps
Webex-appen / Bordtelefon → PSTN via Cloud Connect for Webex Calling	0	0 * 80 kbps
Webex-appen / Bordtelefon → Bedrift via LGW	15	2 * 15 * 80 kbps = 2400 kbps
Webex-appen / Bordtelefon → Webex Calling-talepost	5	5 * 70 kbps = 350 kbps
Totalt antall samtaler / Båndbredde	100 samtaler	14 950 kbps / 14,95 Mbps

Tabell 4. Brukerovergangsplan etter nettsted
Brukernettsted / sted	Informasjon og opplæring før overgang	Overgangsperiode	Støtte etter overgang
NYC (1525 brukere)	Uken 1. april	15. april – 27. april	Uken som startet 29. april
SFO (1600 brukere)	Uken 6. mai	20. mai – 31. mai	Uken 3. juni
RTP (1 275 brukere)	Uken 3. juni	17. juni – 28. juni	Uken 1. juli

Tabell 5. Rapporter generert fra Unified CM .tar-fil
Rapportnavn Rapportbeskrivelse
ImportedDataBulk.csv Alle brukere og enheter fra Unified CM-data
DeviceEligibility.csv Identifiserer enheter som er kvalifisert for migrering til Webex Calling (IP-telefoner, rom-OS-enheter, ATA-er og tredjepartsenheter)
DevicePoolNumbers.txt Liste over alle numre i en bestemt enhetspool
HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv Detaljer om enheter og brukere som skal migreres sammen basert på delte linjer, Hunt Pilot, samtalekø, samtaleparkering og konfigurasjon av samtalehentingsgruppe
HuntGroupMigrationInsight.csv Detaljert informasjon om tildelte jaktlinjer, linjegrupper og tilknyttede agenter
SharedlineGroupMigrationReport.csv Oversikt over hvordan telefonnumre (katalognumre) deles mellom brukere

Tabell 6. Rapporter generert fra Unified CM .tar- og CDR.gzip-filer
Rapportnavn Rapportbeskrivelse
FeatureUsageBasedDeviceEligibilityReport.csv Informasjon om kvalifisering for enhetsmigrering basert på funksjonsbruk
FeatureUsageWithLastUsageDateReport.csv Brukstelling for antall ganger jaktpilot(er) og anropskø(er) har blitt anropt, sammen med siste bruksdato.
UserWorkspaceLastUsage.csv Siste bruksdato for brukere og arbeidsområder for både programvareklienter og harde telefoner
DIDUsageReport.csv DID-bruk for både tildelte og ikke-tildelte DID-er

Tabell 7. inkluderte opptaksalternativer
Webex	Dubber Go
Tilgjengelig for alle brukere	Tilgjengelig for alle brukere
Ubegrensede opptak	Ubegrensede opptak
1 års oppbevaringsperiode*	30-dagers oppbevaringsperiode
100 GB lagringsplass per organisasjon	-
Samsvarsansvarlige kan få tilgang til og administrere samtaleopptak	-
API-er for å administrere opptak	-
Administratorer kan konfigurere og administrere brukernes tilgang til samtaleopptakene sine Brukere kan administrere sine egne opptak ved hjelp av brukerhub and/or Webex-appen.	Bare brukere kan få tilgang til og administrere opptakene sine Fra dubberportalen deres.

Plan

Overordnet prosjektplan

Migrasjonsreise – ett eller to steg?

Alternativ 1: Brukermigrering i ett trinn

Alternativ 2: Brukermigrering i to trinn

Trinn 1

Trinn 2

Overordnet prosjektplan

Når man utvikler en prosjektplan på overordnet nivå for migrering fra til , er det viktig å etablere tydelige faser og milepæler som samsvarer med både forretningsmål og tekniske krav. Planen bør starte med en omfattende vurderingsfase, inkludert innsamling av detaljerte tekniske og forretningsmessige krav, samt identifisering av interessenter og definering av suksesskriterier. Viktige hensyn inkluderer ressursallokering, tidslinjeestimering, risikostyring og kommunikasjonsstrategier for å sikre at alle parter er informert og engasjert gjennom hele migreringen. I tillegg bør planen inkludere valideringskontrollpunkter som pilottesting og fasede utrullinger for å minimere forstyrrelser og tillate justeringer basert på tilbakemeldinger.

Eksempler på elementer som bør inkluderes i prosjektplanen er:

Definere omfanget av migreringen (f.eks. hvilke brukere, enheter og funksjoner som skal overføres)

Planlegging av opplæringsøkter for sluttbrukere og supportteam

Koordinering av vurderinger av nettverksberedskap, og

Planlegging av overgangsaktiviteter med reservealternativer. Det er også viktig å integrere samsvars- og sikkerhetsgjennomganger, samt støtte- og optimaliseringsfaser etter migrering.

Ved å strukturere prosjektplanen med disse hensynene, kan organisasjoner bedre håndtere kompleksitet, redusere risikoer og oppnå en smidigere overgang til .

Migrasjonsreise – ett eller to steg?

krever at brukerne bruker for sin kallende programvareklient. Derfor, hvis noen brukere fortsatt bruker , har du to alternativer for når du kan flytte dem til . Du kan enten gjøre en brukermigrering i ett trinn eller en brukermigrering i to trinn.

Alternativ 1: Brukermigrering i ett trinn

I en enkelttrinnsmigrering går brukerne over fra til samtidig som de overføres fra Unified CM til . Dette alternativet er vanligvis for kunder med et lite antall brukere å migrere, og som kan administrere flytting av både brukerens programvareklient og anropstjeneste til samtidig. Figuren Brukerens anropstjeneste, myk klient & Telefonen migrerer til samtidig nedenfor fremhever denne typen migrering. Med dette alternativet vil en bruker få følgende fullført samtidig:

Anropstjenester flyttet fra til

Telefonnumre og internnumre flyttet fra til

Myk klient overført fra Jabber til - vil registrere seg til

Telefonregistrering flyttet fra til.

Brukerens anropstjeneste, myk klient & telefonen flyttes til samtidig

Dette kan fortsatt være en faseinndelt migrering der grupper av brukere flyttes til forskjellige tider, men når hver bruker flyttes, skjer alt dette samtidig.

Alternativ 2: Brukermigrering i to trinn

Den andre tilnærmingen er en migrering i to trinn. I trinn 1 blir brukerne overført fra til , men forblir på for anropstjenester. I trinn 2 flyttes brukerne deretter fra Unified CM til . Dette alternativet anbefales for større kunder som vil administrere endringer i sluttbrukeren og som ønsker å skille brukerens endring av den myke klienten fra endringen av den kallende tjenesten. Følgende figur Migrer programvareklient; migrer deretter anropstjeneste, programvareklient & telefon til Webex Calling nedenfor fremhever denne typen migrering.

Trinn 1

Myk klient overført fra til - vil registrere seg til .

Trinn 2

Anropstjenester flyttet fra til .

Telefonnumre og internnumre flyttet fra til .

registreringen flyttet fra til.

Telefonregistrering flyttet fra til.

Migrer programvareklienten; migrer deretter anropstjenesten, programvareklienten & telefon til Webex Calling

Dette kan fortsatt være en faseinndelt migrering der grupper av brukere flyttes på forskjellige tidspunkter i begge trinn.

Alternativet du velger avhenger av hvordan du vil administrere brukernes overgang til og . Anbefalingen er å ta det i trinn (alternativ 2). Dette lar deg minimere sluttbrukerens endringer samtidig og fordele innsatsen på tvers av ulike deler av prosjektet. Hvis du imidlertid foretrekker at brukerne bare påvirkes én gang, er det også gyldig å bruke alternativ 1.

Når vi ser på den anbefalte reisen (alternativ 1), viser overordnet overgangskart for Jabber til Webex-appen figuren nedenfor overgangen på overordnet nivå for trinn 1.

Overgangskart for Jabber til Webex-appen på høyt nivå

I dette trinnet går brukerne over fra Jabber til for alle sine ringetjenester. Ringeplattformen er imidlertid fortsatt Unified CM, og de vil registrere ringetjenestene sine til . Som vist i figuren for overordnet overgangskart fra Jabber til Webex-appen, endres ikke den lokale infrastrukturen, og den fungerer på samme måte som Jabber. Den eneste endringen er at det kreves en tilkobling ut til .

Hvis du vil ha mer informasjon om denne overgangen, kan du se Overgangskart og distribusjonsveiledning for Jabber til Webex under Klient-delen på siden Samarbeidsovergang.

Overgangskart for høyt nivå fra Unified CM til Webex Calling Figuren er overgangen på høyt nivå fra til . Dette er trinn 2 av den anbefalte reisen.

Overgangskart for Unified CM til Webex Calling på høyt nivå

Hvis du bestemmer deg for å bruke ett-trinnsmetoden, gjelder dette også.

I dette trinnet blir brukerne overført til grupper. På dette tidspunktet begynner brukerne å bruke tjenestene sine, ringeregistrering og IP-telefonregistrering.

Siden brukerne flyttes i grupper, vil Enterprise-brukere bli delt mellom de to anropsplattformene under overgangen. Fase 1 i Overgangskart for Unified CM til Webex Calling på høyt nivå -figuren viser denne tilstanden. I denne fasen kreves det planlegging for hvordan samtaler mellom brukere på de to plattformene skal håndteres og hvordan PSTN-samtaler skal rutes. Hver gang en gruppe brukere overføres til , vil det være nødvendig med oppdateringer av oppringingsplaner og samtaleruting på og den/de lokale gatewayen(e).

Når alle brukere, programvareklienter og enheter er overført til (fase 2), kan all lokal UC-infrastruktur fjernes og avvikles.

Design

Valg av region

Steder

PSTN

Oppringingsplan

Lokal oppringingsplan inn

oppringingsplan

Innspilling

1. Valg av leverandør av samtaleopptak

2. Valg av region

Nødanrop

Lisensiering

Manuell tildeling gjennom

Maler for automatiske lisenstildelinger

Massetildeling via CSV-mal

API-basert tildeling

Lisenskrav

Brukerklargjøring

Brukergrupper

Anbefalt tilnærming ved migrering fra til

Utforming av brukergrupper

Enkel pålogging (SSO)

Støtte for flere IdP-er

1. Fusjoner og oppkjøp

2. Flere uavhengige IT-avdelinger

3. Ulike brukergrupper eller domener

4. Støtte for ulike autentiseringsprotokoller

5. Forbedret sikkerhet og samsvar

6. Forenklet brukeropplevelse

Duo MFA med SSO for

Funksjoner

Automatisk assistent

Samtaleparkering

Samtalehenting

Samtalekø

Hunt Group

Driftsmoduser

Personsøkergruppe

Opptak

Enkeltnummer rekkevidde

Talepostgruppe

Valg av region

er tilgjengelig globalt og leveres fra redundante datasentre i flere regioner: USA (Dallas, Chicago), Canada (Vancouver, Toronto), Europa (Frankfurt, Amsterdam), Storbritannia (London, Manchester), Australia (Melbourne, Sydney), Japan (Tokyo, Osaka), Saudi-Arabia (Riyadh, Jeddah) og India (Mumbai, Chennai). Medie-PoP-ene tilbyr medietjenester for å optimalisere medietransporttider. Datasenteret i Singapore brukes for eksempel til å optimalisere tur-retur-tider for medier for kunder i asiatiske land, der tur-retur-tidene til enten Australia eller Japan kan være suboptimale. Datasentrene er sammenkoblet av et multi-gigabit og fullstendig redundant stamnett. Figuren globalt distribuerte datasentre viser en oversikt over alle datasentre. For den nyeste listen over tilgjengelige datasentre, se Datasenterplasseringer for Webex Calling.

Globalt distribuerte datasentre

Hver kunde er klargjort på én av instansene. All klargjøringsinformasjon for den kunden lagres i den instansen, og SIP-signaleringen fra alle endepunkter og lokale gatewayer som er klargjort for den kunden, er knyttet til instansen kunden er klargjort på. Fordi det er vanskelig å endre det opprinnelige regionvalget, er det viktig å vurdere alle relevante faktorer som en del av beslutningsprosessen som fører til regionvalget. For å unngå for lang forsinkelse i signaliseringen, er det viktig å bestemme tidlig i overgangsprosessen hvilken instans som skal brukes. Cisco anbefaler å velge instansen som gir de laveste signaleringstidene for det største antallet brukere i distribusjonen.

For tilgjengelighet i ulike land, se Hvor er Webex tilgjengelig?.

Steder

For å forberede klargjøring av lokasjoner må den nødvendige informasjonen for alle migreringsmålsteder samles inn. Informasjonen som trengs for hvert sted er oppsummert i Informasjon som skal registreres for hvert sted.
Tabell 1. Informasjon som skal samles inn for hvert sted
Informasjon Kommentar
Utvidelsesområde(r) Hvert sted kan ha utvidelser som starter med forskjellige sifre. Ett siffer må være avsatt for styringssifferet for oppringing mellom lokasjoner (for eksempel 8) og ett for styringssifferet for PSTN (for eksempel 9). Ingen utvidelsesområder kan starte med noen av disse to sifrene.
Alle forlengelsesområder for alle lokasjoner må være like lange.
DID-område(r) -
PSTN-styringssiffer -
Nettstedskode Alle nettstedskoder for alle steder må være unike og ha samme lengde.
Hovednummer Når du oppretter en lokasjon, må to DID-er klargjøres. Ett som hovednummer (for eksempel for å bli tilordnet en automatisk svartjeneste) og ett for telefonsvarerportalen.
Tildel én DID for talepostnummeret.
Telefonsvarernummer
Antall lisenser Nødvendige lisenser etter type, inkludert Standard, Profesjonell, Arbeidsområde, Ruteliste, Utgående anropsavtale.
Samtidige samtaler i den travle timen Summen av samtidige samtaler mellom enheter og mellom enheter og den lokale gatewayen (PSTN og samtaler til enheter). Trenger å bestemme nødvendig båndbredde for internettilgang.
Land -
Tidssone -
Språk -
Kontakt (navn, telefon, e-post) -
Adresse (gateadresse, by, stat, postnummer) -
Fysisk utsendelsessted for nødetater for endepunkter Enhetsadresse som kan sendes til nødanrop inkluderer vanligvis følgende: bygningsadresse, bygningsadresse + etasjenummer, bygningsadresse + leilighetsnummer eller bygningsadresse + etasjenummer + office/cubical tall.
Unik fysisk nettverksplassering per enhet for nødetater Fysisk nettverksplassering for nødanrop inkluderer vanligvis følgende: bryter / switchport for kablede enheter, trådløst tilgangspunkt (AP) Basic Service Set Identifiers (BSSID-er) for trådløst tilkoblede enheter, and/or Lokale IP-delnett for endepunktenheter.

PSTN

Når kunder utformer en distribusjon, har de tre primære PSTN-tilkoblingsalternativer: Cisco Calling Plans (en skylevert PSTN-tjeneste administrert av Cisco), Cloud Connected PSTN Providers (CCPP, der leverandører leverer PSTN-tjenester gjennom skyen) og lokale PSTN (der lokale gatewayer kobler bedriftsnettverket til PSTN-et). Med introduksjonen av PSTN-trunking for hybriddistribusjoner (for mer informasjon, se PSTN-trunking for hybrid Webex Calling-distribusjoner på PSTN-trunking), får organisasjoner ytterligere fleksibilitet i migreringstilnærmingen. Denne funksjonen lar kunder flytte PSTN-en sin til CCPP i starten av overgangsprosessen og begynne overgangen til skybasert PSTN for brukere, samtidig som CCPP utnyttes til å opprettholde PSTN-tjenesten for brukere som forblir på Cisco under en faset migrering.

Denne hybride tilnærmingen lar organisasjoner flytte utvalgte brukergrupper til skyen først, uten å umiddelbart måtte overhale hele telefonimiljøet. Det introduserer imidlertid ytterligere kompleksitet og risiko, spesielt rundt tilpasning av eksisterende logikk for samtaleruting for å støtte den nye arkitekturen. Interoperabilitet med eldre applikasjoner, som faksservere, kontaktsentre eller personsøkersystemer, krever også nøye vurdering. Viktige tekniske utfordringer kan omfatte å sikre sømløs ende-til-ende-kodekforhandling og DTMF-signalering (Dual-Tone Multi-Frequency) på tvers av det blandede miljøet, samt å validere kompatibilitet med spesialiserte telefonifunksjoner. Riktig planlegging og testing er avgjørende for å minimere avbrudd og opprettholde pålitelige taletjenester gjennom hele migreringsprosessen. I tillegg er kommersielle hensyn viktige, ettersom hybrid trunking krever en brukslisens som er basert på antall samtidige samtaler mellom det lokale miljøet og den skytilkoblede PSTN-leverandøren (CCPP).

Alternativt kan organisasjoner velge å beholde sin lokale PSTN-tilkobling gjennom hele overgangsfasen. I dette scenariet kan migrering til CCPP utføres på to måter: som en enkelt, koordinert overgang for alle brukere og steder når migreringen er fullført, eller trinnvis, med PSTN-migrering som skjer per sted etter hvert som brukere flyttes til . Denne tilnærmingen kan bidra til å effektivisere sameksistens og opprettholde kontinuitet for eldre integrasjoner, men den introduserer flere driftsmessige kompleksiteter. Blant disse er utfordringer knyttet til nummerportering, som behovet for presis koordinering av nummerporteringsordrer, potensielle forsinkelser og leverandørpålagte begrensninger, som et tak på antall samtidige porteringsforespørsler eller restriksjoner på portering av delsett av store tallblokker. Organisasjoner må nøye planlegge sin PSTN-overgangsstrategi, og ta hensyn til disse logistiske hensynene for å unngå tjenesteavbrudd og sikre en problemfri migreringsopplevelse.

Migrering til CCCP i starten kontra å beholde lokalt PSTN

Figuren Migrering til CCCP ved oppstart kontra å beholde lokalt PSTN viser de to PSTN-migreringsalternativene som er forklart ovenfor. Illustrasjonen til venstre viser scenariet der alle lokale brukere og applikasjoner forbruker skytilkoblede PSTN-tjenester gjennom en lokal trunk og en lokal gateway som kobler den lokale til, mens illustrasjonen til høyre viser scenariet der den eksisterende lokale PSTN-en forblir på plass, og brukere på Webex Calling bruker lokale PSTN-tjenester gjennom den lokale gateway-tilkoblingen mellom lokale og . Under overgangen kan steder byttes til å bruke skytilkoblet PSTN.

I begge scenariene bruker samtaler mellom lokale enheter og brukere den lokale gateway-tilkoblingen. Forbindelsen mellom den lokale og må utformes og dimensjoneres deretter basert på forventet antall samtidige samtaler og nødvendig redundans.

Oppringingsplan

For å oppnå sømløs interoperabilitet mellom og under migreringsperioden, må en omfattende arkitektur for oppringingsplaner utvikles og implementeres på tvers av begge plattformene. Denne designen med to plattformer for oppringingsplan sikrer konsekvent samtaleruting, nummeroversettelse og funksjonsgjennomsiktighet, slik at brukere på begge systemene kan kommunisere uten tjenesteforringelse eller forstyrrelser i brukeropplevelsen gjennom hele sameksistensfasen.

Lokal oppringingsplan inn

For å tillate sameksistens mellom enheter registrert på Unified CM og på bedriftens oppringingsplan under overgangen, må dette endres slik at minst følgende krav kan oppfylles:

+E.164 ringer fra til

Oppringing av internnummer fra til (intra-site, men også inter-site hvis internnummerrekkeviddene er unike)

Forkortet oppringing mellom steder fra til

Tvungen oppringing på nettet fra til

Tilbakeringing fra katalogen for tapte anrop til destinasjoner på

PSTN-anrop fra til PSTN hvis lokal PSTN brukes under overgangen

PSTN-anrop fra til hvis PSTN-trunking for hybriddistribusjoner brukes under overgangen til å gi PSTN-tilgang til lokale brukere via Cloud Connect for

Tvunget på nettet fra til

Internnummer som ringer fra til (mellom lokasjoner).

Hvis noen av de ovennevnte ikke støttes som oppringingsvaner før overgangen, for eksempel hvis det ikke finnes noen forkortet oppringingsvane mellom steder, trenger de ikke nødvendigvis å introduseres under overgangen.

Figuren Beste praksis for oppringingsplan viser beste praksis for oppringingsplantilnærming som beskrevet i Foretrukket arkitektur for Cisco Collaboration 12.x Enterprise On-Premises Deployments, CVD. Viktige kjennetegn ved denne tilnærmingen inkluderer:

Enkelt partisjon for +E.164 katalognumre

Kjerneruting basert på +E.164 rutemønstre

Normalisering av alle oppringingsvaner til +E.164 ved hjelp av oversettelsesmønstre

Bruk av oversettelsesmønster som kaller arv av søkerom (alternativ Bruk opphavsmannens kallende søkerom satt på oversettelsesmønstre).

Beste praksis for oppringingsplan

For eksempel PSTN-oppringing (9+1+10D) fra en enhet i SJC som er klargjort med linjeanropssøkeområde vil SJCInternational først bli matchet av 9.1[2-9]XX[2-9]XXXXXX oversettelsesmønster som normaliserer nummeret til den oppringte parten til +E.164. Det sekundære oppslaget bruker deretter det samme kallende søkerommet SJCInternational igjen (kaller arv av søkerommet) og +E.164-digit strengen vil enten bli matchet av en +E.164 katalognummeret i DN -partisjonen eller av et av PSTN-rutemønstrene i USPSTNNational - eller SJCPSTNLocal -partisjonen. Forkortede oppringingsvaner innen og mellom steder implementeres av oversettelsene i partisjonene ESN og SJCtoE164. Selv om ESN -partisjonen er en global partisjon (tilgjengelig for telefoner på alle steder), er SJCTOE164 -partisjonen bare tilgjengelig for brukere på sted SJC. Dette forutsetter overlappende utvidelsesområder.

Det første trinnet for å aktivere anrop fra til er å sørge for at +E.164 destinasjoner blir rutet deretter. Dette kan oppnås ved å legge til en partisjon i oppringingsplanen, legge til +E.164 rutemønstre for alle destinasjoner til den partisjonen, og til slutt legge til partisjonen i alle kallende søkeområder som representerer tjenesteklasser som må kunne nå . Det kreves å opprette en dedikert partisjon for å muliggjøre opprettelse av en differensiert tjenesteklasse for anrop som stammer fra . For å unngå anropsløkker skal ikke søkeområdet for innkommende anrop på trunk-en fra den lokale gatewayen ha tilgang til partisjonen.

+E.164 ruting til Webex Calling

Som vist i figur +E.164 ruting til Webex Calling, for å aktivere ruting fra til for en plassering med +E.164 DID-område +1 221 555 2XXX og områdekode 121, et hasterutemønster som samsvarer med dette +E.164 området må legges til i -partisjonen.

Hvis det ikke kreves noe stedsspesifikt valg av lokal gateway, kan rutemønstre som peker til en enkelt rutegruppe, i stedet for å bruke en ruteliste med en lokal rutegruppe som destinasjon, klargjøres med den lokale gatewayen som eneste medlem, og deretter peker rutemønstrene til en enkelt ruteliste med denne ene rutegruppen som eneste oppføring.

For å aktivere kortnummeroppringing mellom lokasjonene legges det nødvendige rutemønsteret 8121.2XXX til partisjonen. For at nettsteder skal gå over til et oppringingsnormaliseringsmønster 8121.2XXX som normaliserer ESN-oppringing til +E.164 finnes kanskje allerede i ESN partisjonen. I så fall ser 8121.2XXX ut til å være overflødig, men så snart alle DN-er for den respektive lokasjonen er migrert over til 8121.2XXX oppringingsnormaliseringsmønsteret, kan oversettelsesmønsteret fjernes, og da aktiverer rutemønsteret 8121.2XXX ESN-oppringing selv for brukere av kun internnummer i det området.

Med disse endringene i oppringingsplanen kan anrop til stedet ikke bare foretas ved å ringe forkortede numre mellom steder, men også +E.164. Internasjonal og nasjonal PSTN-oppringing er også mulig fordi disse oppringingsvanene først normaliseres til +E.164 gjennom de allerede eksisterende oversettelsesmønstrene for oppringingsnormalisering og deretter bli rutet til ved å matche +E.164 rutemønster i partisjonen.

De +E.164 Rutemønstersamsvar på stedets DID-område kan klargjøres mens alle DID-er fortsatt er lagret på . Den beste algoritmen for samsvarsmønster sørger for at når et nummer som er lagret på [server] blir ringt, så +E.164 katalognummeret som er klargjort for, samsvarer bedre enn jokertegnet +E.164 rutemønster som peker til slik at samtalene blir videreført til en linje på og ikke sendt til .

oppringingsplan

Hver bruker er utstyrt med en utvidelse and/or en +E.164 telefonnummer. Forlengelseslengden er en fast global innstilling: Alle utvidelser i en distribusjon har samme lengde. Oppringing av internnummer kan brukes mellom brukere både innenfor et sted og mellom steder. Forkortet oppringing mellom lokasjoner (sistnevnte tilfelle) fungerer bare hvis den oppringte internnummeret er unikt.

Hvis forkortet oppringing mellom lokasjoner er et krav, men det er overlappinger mellom internnumre som er tilordnet på forskjellige lokasjoner, må det opprettes en bedriftsspesifikk nummerplan ved å gi internnumrene en tilgangskode (eller lokasjonskode) foran. Hvis du vil ha mer informasjon, kan du se Foretrukket arkitektur for Cisco Collaboration 15 lokale distribusjoner, designoversikt tilgjengelig på Cisco Collaboration foretrukne arkitekturer.

Lengden på internnummeret, oppringingsatferden til internnummeret, prefikslengden for interlokasjonsoppringing og styringssifferet i rutingsprefikset for interlokasjonsoppringing konfigureres i innstillingene for anropstjenesten i :

Lengde på prefiks for lokasjonsruting: Prefikslengde inkludert styresifferet. Kun nødvendig hvis en bedriftsnummerplan må etableres som alternativ forkortet oppringing mellom bedrifter.

Styringssiffer i ruteprefiks: Styresiffer for forkortet oppringingsrutine for bedrifter. Overlapping med det første sifferet i en hvilken som helst lokasjon og utgående sifre for lokasjon bør unngås. Kun nødvendig hvis en bedriftsnummerplan må etableres som alternativ forkortet oppringing mellom bedrifter.

Intern forlengelseslengde: Standard lengde på forlengelser. Kan være en hvilken som helst verdi mellom to og ti.
Når det kreves oppringing av internnummer eller oppringing ved hjelp av viktige bedriftsnumre (styringskode, stedskode, internnummer) fra en lokal samtalekontroll til , og den lokale samtalekontrollen sender en internnummer som innringer-ID, må du også sørge for å angi parameteren Maksimal ukjent internnummerlengde i delen Samtaleruting mellom og lokaler for å sikre at oppstrømsanrop fra den lokale samtalekontrollen til kan klassifiseres som lokale anrop riktig.

Tillat oppringing av internnummer mellom lokasjoner: Veksle til enable/disable oppringing av internnummer mellom lokasjoner. Dette alternativet bør bare aktiveres hvis alle utvidelser i organisasjonen er unike. Hvis alternativet er deaktivert, må viktige bedriftsnumre (styringskode, stedskode, internnummer) eller telefonnumre ringes mellom lokasjoner.

De tre første parameterne brukes hovedsakelig til å bygge en oppringingsplan for telefoner for å minimere tidsavbrudd mellom sifre når man bruker oppringing uten rør. Avvik fra disse globale innstillingene er fortsatt mulige (eksempel – internnumre med en annen lengde kan klargjøres), men en advarselsmelding vil dukke opp i Control Hub, og oppringing fra telefoner kan kreve blokkering av oppringing for å unngå konflikter innenfor den forhåndsinstallerte oppringingsplanen.

Tabellen Eksempel på bedriftsnummerering viser et eksempel på tre lokasjoner der internnummerområdene til to lokasjoner, NYC og RTP, er identiske. Etablering av et nummereringsskjema for bedrifter med styringssifferet 8mellom lokasjoner, etterfulgt av en tresifret lokasjonskode og den firesifrede utvidelsen, skaper en ikke-overlappende forkortet oppringingsrute mellom lokasjoner.

Tabell 2. Eksempel på bedriftsnummerering
Nettsted Utvidelsesområde Nettstedskode Bedriftsserien

NYC 2XXX 202 8 202 2XXX

SFO 3XXX 203 8 203 3XXX

RTP 2XXX 204 8 204 2XXX

For å muliggjøre en smidig overgang, bør oppringingsvanene for brukere før og etter overgangen til ideelt sett være de samme. For å forberede overgangen for hver lokasjon må DID-områdene og internnummerområdene (eller forkortede oppringingsvaner innenfor stedet) dokumenteres. Basert på denne informasjonen må styringssifret mellom stedene velges.

Tabellen Forlengelsesområder med fast lengde viser et eksempel på tre plasseringer og forlengelsesområder med fast lengde. Fordi overlappende oppringingsvaner må unngås, er det viktig å sørge for at det første sifferet i området for ethvert internnummerområde ikke samsvarer med styringssifferet for forkortet oppringing mellom steder. Hvis for eksempel 8 er valgt som styresiffer for oppringing mellom lokasjoner, kan ingen internnummerrekkevidde på noe lokasjon starte med 8. Vanligvis samsvarer internlinjene på en gitt plassering med de siste sifrene i DID-ene som er tilordnet den plasseringen. For å unngå konflikter kan det første sifferet i internnummeret endres. Hvis for eksempel DID-er i +1 408 555 8XXX-området brukes på et sted, og i stedet for å bruke 8XXX som internnummerområde kan 7XXX brukes for internnummerne på det stedet.

Tabell 3. Forlengelsesområder med fast lengde
Nettsted Utvidelsesområde Utvidelser Nettstedskode Bedriftsserien

NYC 2XXX 2XXX 202 8 202 2XXX

SFO 8XXX 7XXX 203 8 203 7XXX

RTP 1XX 11XX 204 8 204 11XX

Syvsifrede oppringingsstrenger som ringes opp på en enhet med den amerikanske oppringingsplanen overlapper med et syvsifret mønster for lokal oppringing i den forhåndslastede amerikanske oppringingsplanen. For å unngå overlappinger mellom oppringingsvaner på og utenfor nettet (PSTN), kan en obligatorisk ekstern tilgangskode brukes på det stedet. Hvis det eksisterende nummereringsskjemaet for bedrifter og den tilsvarende forkortede oppringingen mellom steder overlapper med mønstre i det nasjonale oppringingen, kan nummereringsskjemaet også endres til en lengre eller kortere form for å unngå overlappinger under overgangen til nummereringsskjemaet. Den enkleste måten å oppnå dette på er å legge til et ekstra utfyllingssiffer i nummereringsskjemaet. Det nye, lengre oppringingsskjemaet mellom nettsteder trenger bare å tas i bruk av brukere som allerede har migrert til . Brukere som fortsatt er på, kan fortsette å ringe syv sifre. Bedriftens oppringingsplan må i dette tilfellet sørge for at forkortet syvsifret oppringing fra Unified CM blir transformert til enten +E.164 eller til det forkortede oppringingsformatet som er distribuert på . Dette må gjøres før samtalen sendes til den lokale gatewayen.

Tabellen Overgang til sjusifret oppringing viser et eksempel på denne omnummereringen. I dette eksemplet bruker forkortet inter-site oppringing styresifret 8 etterfulgt av en tosifret stedskode og et firesifret internnummer. For å unngå sjusifret forkortet oppringing mellom steder for steder på , kan stedskodene enkelt endres til tresifrede ved å legge til et vilkårlig utfyllingssiffer (8 i eksemplet) foran de tosifrede stedskodene som brukes i , slik at oppringing mellom steder fra telefoner bruker styringssifferet 8 etterfulgt av utfyllingssifferet 8, den gamle tosifrede stedskoden og det firesifrede internnummeret. Brukere på trenger ikke å huske nye stedskoder; de trenger bare å huske å bruke 88 som prefiks for oppringing mellom steder i stedet for 8 på .

Tabell 4. Overgang til syvsifret oppringing

Nettsted Utvidelser Nettstedskode Bedriftsserien Nettstedsode Enterprise angel

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 scenario med forskjellige bedriftsnummerformater på, og hvis bedriftsnumre presenteres som informasjon om den innringere for anrop fra til (for eksempel anrop fra enheter uten DID), er det viktig å også implementere en tilordning mellom de forskjellige nummerformatene for informasjon om den innringere for å sikre at tilbakeringing fungerer. Denne kartleggingen kan oppnås ved å bruke transformasjonsmønsteret for den anropende parten på trunk mellom og den lokale gatewayen.

Innspilling

En godt utformet løsning for samtaleopptak krever nøye vurdering av flere viktige designelementer for å sikre at den er i samsvar med organisasjonens mål, regulatoriske krav og tekniske begrensninger. To av de viktigste beslutningene involverer valg av leverandør og valg av region, som begge må kanskje skreddersys globalt og overstyres på bestemte steder, basert på forretningsbehov.

1. Valg av leverandør av samtaleopptak

Å velge riktig leverandør av samtaleopptak er grunnleggende for å nå forretningsmål og sikre funksjonssamsvar på tvers av organisasjonen:

Valg av global leverandør: Organisasjoner utpeker vanligvis en primær leverandør av samtaleopptak på globalt nivå, noe som sikrer konsistens i funksjonssett, samsvar og støtte på tvers av alle lokasjoner.

Stedsbaserte overstyringer: I tilfeller der bestemte steder eller regioner har unike forretningsbehov eller regulatoriske krav, kan det være nødvendig å overstyre det globale leverandørvalget og spesifisere alternative leverandører for disse stedene. Denne fleksibiliteten støtter varierende samsvarskrav og lokale driftsbehov

Forretningskrav: Valg av leverandør bør styres av en vurdering av forretningsdrivende faktorer som samsvar med regelverk (eksempel - MiFID II, HIPAA), kvalitetssikring, tvisteløsning eller opplæringsbehov.

Funksjonstilgjengelighet: Leverandører bør evalueres basert på deres evne til å levere nødvendige funksjoner, som sanntidsovervåking, søke- og avspillingsmuligheter, kryptering, oppbevaringsregler, integrasjon med analyseplattformer og støtte for ulike samtaletyper (innkommende, utgående, interne).

2. Valg av region

Å bestemme regionen der samtaleopptak lagres og behandles er avgjørende for samsvar og ytelse:

Valg av global region: Som standard kan organisasjoner velge én region for lagring av samtaleopptak for å forenkle administrasjon og styring.

Stedsbaserte regionoverstyringer: Der det kreves det av lover om datalagring eller bedriftens retningslinjer, kan det være nødvendig å overstyre den globale regioninnstillingen for bestemte steder, slik at samtaleopptak lagres og behandles innenfor de nødvendige geografiske grensene.

Krav til datalagring: Utformingen må ta hensyn til internasjonale og lokale personvernforskrifter (som GDPR, CCPA eller landsspesifikke påbud) som kan diktere hvor og hvordan samtaleopptak oppbevares.

Et annet viktig aspekt som må tas i betraktning under planlegging og design av en løsning for samtaleopptak, er estimering av lagringsbehov. Det er viktig å nøyaktig forutsi lagringsbehov for å sikre at det er tilstrekkelig kapasitet tilgjengelig til å støtte løpende forretningsdrift, opprettholde samsvar og unngå tjenesteavbrudd.

Flere viktige parametere bør vurderes når man bestemmer forventet lagringsbehov:

Antall innspilte samtaler: Vurder det forventede antallet samtaler som vil bli registrert innenfor et gitt tidsintervall (f.eks. per dag, uke eller måned). Dette inkluderer ikke bare eksterne samtaler, men også intern kommunikasjon, hvis det kreves av forretningspolicy eller regulatoriske påbud.

Gjennomsnittlig samtalevarighet: Beregn den typiske lengden på innspilte samtaler, ettersom lengre samtaler vil bruke mer lagringsplass. Variasjoner i samtalevarighet på tvers av ulike avdelinger eller brukergrupper bør også tas med i beregningen.

Oppbevaringsperiode: Definer hvor lenge opptak må oppbevares, noe som ofte dikteres av organisasjonens retningslinjer eller eksterne forskrifter (for eksempel bransjespesifikke samsvarsstandarder). Lengre oppbevaringsperioder vil øke det totale lagringsbehovet

Vekstprognoser: Vurder forventet vekst i samtalevolum eller utvidelse av opptaksomfang, som kan følge av skalering av virksomheten, nye regulatoriske krav eller onboarding av flere brukere eller lokasjoner.

Ved å analysere disse parameterne grundig kan organisasjoner utvikle en robust lagringsstrategi som sikrer skalerbarhet, kostnadseffektivitet og samsvar med regelverk for samtaleopptaksløsningen deres. Det er også lurt å regelmessig gjennomgå og justere lagringsallokeringer etter hvert som bruksmønstre utvikler seg over tid.

Nødanrop

Kravet om å rute et nødanrop til riktig alarmsentral er et krav for alle anropstjenester som tilbyr PSTN-tjenester. Med er rutingen av nødanrop innebygd i løsningen og inkluderer støtte for alle nasjonale nødnumre i landene som støtter . Rutingen av et nødanrop er basert på stedet som er definert i stedet og stedets PSTN-tilgangsmetode. Nødnumrene er forhåndsdefinerte og spesifikke for landet der brukerne og enhetene er distribuert.

Det finnes to metoder for å sende nødanrop. Det finnes en grunnleggende tjeneste for ruting av nødanrop og en utvidet tjeneste for ruting av nødanrop. Den grunnleggende tjenesten for ruting av nødanrop bruker et administratorvalgt nummer til å identifisere plasseringen og anropsruten for å nå nødetatene. For grunnleggende nødanrop går anropsveien vanligvis gjennom kundens PSTN-alternativ for det stedet. har også forbedret nødanropsruting utviklet for distribusjoner i USA og Canada som har krav til samsvar med forskrifter som krever bruk av en landsdekkende leverandør for å levere nødanrop til riktig alarmsentral.

Alle kunder bør som et minimum implementere den grunnleggende konfigurasjonen for nødanrop. Grunnleggende nødanrop krever at minst én kunde eies +E.164 nummeret tildeles hvert sted definert i . For grunnleggende nødanrop vil hvert sted være definert av en gateadresse som politi, brannvesen eller ambulansetjenester sendes til i nødstilfeller. I de fleste tilfeller er hovednummeret for stedet det beste valget for å representere den fysiske plasseringen av nødsituasjonen. Vanligvis er tildelingen av adressen til +E.164 Nummeret er koordinert med PSTN-leverandøren. Bildene nedenfor viser tildelingen av hovednummeret som skal brukes som nødnummer for Richardson-lokasjonen.

Lokasjon ECBN-konfigurasjon

I de fleste tilfeller er en bygningsadresse tilstrekkelig som avsenderadresse for stedet. Men hvis det er behov for ytterligere posisjonsdetaljer for bestemte brukere eller enheter, kan en administrator bruke samme prosess som beskrevet ovenfor og tilordne disse enhetene til en bestemt adresse eller en mer presis plassering innenfor adressen (som en etasje eller et rom). I Brukeradministrasjon i , tillater fanen Anrop at et spesifikt nummer brukes for en bruker og enhetene deres for å få en spesifikk mottakeradresse. Følgende bilder illustrerer hvordan et bestemt nummer kan tilordnes en enhet. Administratoren er ansvarlig for å sørge for at nummeret som brukes av enheten, har riktig avsenderadresse tildelt. Adressetildelingen gjøres vanligvis via PSTN-leverandøren på den plasseringen.

Bruker ECBN-konfigurasjon

For USA-baserte telefoniutplasseringer som må tilby forbedrede nødanropsløsninger, brukes RedSkys Horizon Mobility integrert i ruting av nødanrop. Når du bruker RedSky til samtaleruting, må en administrator registrere en konto gjennom Cisco og konfigurere riktig informasjon i Ringer -> Tjenesteinnstillinger for å aktivere denne funksjonen. Når RedSky-tjenesten er aktivert på systemnivå, vil en administrator aktivere RedSky-tjenesten på hvert lokasjonsnivå. Aktivering av Utvidet Nødanrop på et sted vil aktivere tjenesten for alle enheter som er tilordnet det stedet. Enheter som støtter forbedrede nødanrop er Cisco MPP-telefoner, Cisco PhoneOS-telefoner og Ciscos .

Det finnes to innstillinger for å aktivere utvidet nødanrop på et sted. Valget Tillat RedSky å motta informasjon om nettverkstilkobling og testkall bør brukes til å bekrefte at RedSky-konfigurasjonen for enhets- og infrastrukturtilordninger er riktig. Denne innstillingen tillater også testsamtaler til 933 for å utføre posisjonsverifisering ved hjelp av RedSkys IVR-system for å lese ut innringerens posisjon. Selv om dette dokumentet ikke dekker RedSky-konfigurasjonen for posisjonssporing, bør en administrator ALLTID teste posisjonsoppdagelsen sin før nødanrop aktiveres for å rutes til RedSky. Når testingen er fullført og bekreftet som nøyaktig, vil administratoren rute anrop til RedSky ved å slå av og på ruten av nødanrop til RedSky. Denne veksleknappen vil viderekoble alle nødanrop for stedet til RedSky for levering til svarsentralen for stedet.

Innstillingene for forbedret nødanrop gjelder også for klienter både lokale og eksterne. Når de er lokale, kan de spores på samme måte som bordtelefoner spores. Når brukeren er utenfor lokaler, vil vedkommende kunne angi plasseringen sin dynamisk direkte i . Hvis du vil ha mer informasjon om nødanrop, kan du se Utvidet nødanrop for

Lisensiering

Det finnes flere alternativer for å tildele lisenser til brukere.

Manuell tildeling gjennom

Administratorer tildeler lisenser manuelt til individuelle brukere via grensesnittet.

Administratorer kan redigere tjenestelisenser for individuelle brukere og tilordne anropslisenser direkte.

Maler for automatiske lisenstildelinger

Bruk lisenstildelingsmaler for å automatisk tilordne lisenser til brukere basert på gruppe- eller organisasjonsinnstillinger.

Automatisk lisensiering kan gjøres gjennom katalogsynkronisering eller manuelle brukeroppdateringer, men brukere må ha et gyldig +E.164 formatert telefonnummer, og telefonnumrene må finnes på et sted før brukerklargjøring. Hvis betingelsene ikke er oppfylt (f.eks. ugyldig telefonnummerformat), vil ikke lisenser bli tildelt.

Massetildeling via CSV-mal

Last opp en CSV-fil med brukerdetaljer og lisenstildelinger for å legge til eller endre flere brukere samtidig.

CSV-import støtter legge til opptil 20 000 brukere og tildeling av lisenser, men lisenser krever spesifikke felt som telefonnummer og internnummer.

API-basert tildeling

Bruk API-er til å tilordne lisenser programmatisk og administrere brukere.

støtter API-operasjoner for bruker- og lisensadministrasjon (People, SCIM 2.0 og Licenses API-er), som kan utnyttes til automatisering av lisenstildeling. Lisens-API-et tillater samtidig tildeling av lisenser, telefonnumre og internnumre.
Tabell 5. Alternativer for brukerklargjøring – sammendrag
Tildelingsmetode Fordeler Ulemper
Manuell gjennom Enkelt for få brukere.
Gir presis og detaljert kontroll over lisenstildeling.
Ikke skalerbar, tidkrevende
Utsatt for menneskelige feil ved manuell inntasting.

Automatiske lisensmaler Skalerbar
Reduserer manuelle feil
Kan brukes på nye og eksisterende brukere.
Krever gyldige telefonnumre og steder.
Mer komplekst å sette opp
Krever også brukergrupper per brukergruppe med tilsvarende lisenskrav.

Masseopplasting av CSV Effektiv for store brukergrupper
Tillater samtidig tildeling av lisenser, telefonnumre og internnumre.
Krever nøye CSV-formatering
Mulighet for feil hvis telefonnumre eller internnumre mangler eller er feil.
API-basert tildeling Automatiserbar, fleksibel.
Tillater samtidig tildeling av lisenser, telefonnumre og internnumre.
Krever utvikling og API-kunnskap.

Tabellen Brukerklargjøringsalternativer - sammendrag oppsummerer brukerklargjøringsalternativer og deres fordeler og ulemper. Denne oversikten hjelper deg med å velge den beste lisenstildelingsmetoden basert på kundens organisasjonsstørrelse, automatiseringsmuligheter og brukerprovisjoneringsprosesser og -krav.

Der det er mulig anbefaler Cisco å tildele anropslisenser ved hjelp av lisensmaler. Dette krever at det for hver brukergruppe som krever et unikt sett med lisenser (eksempel - Standard vs. Profesjonell), finnes en gruppe med de respektive gruppemedlemskapene. Som omtalt i avsnittene Brukergrupper kan brukergrupper defineres manuelt i eller synkroniseres fra en bedriftskatalog. En kombinasjon av begge tilnærmingene er mulig.

Brukere som tilhører flere grupper får lisenser fra alle tildelinger som er brukt på alle gruppene deres. Dette tillater bruk av lisensspesifikke sikkerhetsgrupper i bedriftskatalogen for å administrere lisenstildeling der den resulterende brukerlisenstildelingen kontrolleres av foreningen av gruppemedlemskap.

Hvis du vil ha mer informasjon, kan du se Konfigurere automatiske lisenstildelinger i Control Hub og Konfigurere automatiske lisenstildelingsmaler for Webex Calling-brukere.

Lisenskrav

Denne delen dekker kun relaterte lisenser. Andre lisenstyper (eksempel – registrering av Webex-enheter, meldinger, møter) dekkes ikke. Som en del av designprosessen må lisenskravene fastsettes. Antall lisenser for følgende lisenstyper må beregnes:

Standard: antall individuelle brukere som trenger standard telefonifunksjoner.

Profesjonell: antall brukere og arbeidsområder som krever avanserte telefonifunksjoner. Virtuelle linjer og gruppe-talepost har rett til en 1:1 forholdet for hver profesjonell lisens. I sjeldne tilfeller der antallet nødvendige virtuelle linjer eller gruppe-talemeldinger overstiger antallet brukere og arbeidsområder som krever avanserte telefonifunksjoner, må det derfor tas hensyn til ytterligere profesjonelle lisenser.

Arbeidsområde for fellesområde: antall steder med delt bruk eller fellesområder som krever standard ringemuligheter.

Kundeservice: antall agenter og veiledere som krever Customer Assist-funksjoner. Kundestøtten inkluderer den profesjonelle lisensen.

Rutelisteanrop: antall nødvendige skytilkoblede PSTN-anrop mellom lokale brukere and/or lokale spesialiserte tredjepartsapplikasjoner.

Attendant-konsoll: antall brukere som trenger tilgang til klienten for attendant-konsollen.

Cisco-anropsabonnement (utgående anropsabonnement): antall brukere som trenger et PSTN-nummer and/or tilgang til utgående PSTN-anrop for Cisco PSTN-tjenesten.

Det finnes ingen dedikert lisenstype for profesjonelle arbeidsområder. Profesjonelle arbeidsområder bruker en profesjonell lisens.

Arbeidsområder kun for hot desking tilbyr hot desking-vertstjenesten og nødanrop fra hot desking-verten og krever ingen lisens. Hvis du vil ha mer informasjon, kan du se Legge til og administrere enheter kun for aktivt skrivebord.

For å bestemme den nødvendige lisenstypen for hver bruker og arbeidsområde basert på nødvendige funksjoner, se Funksjoner tilgjengelig etter lisenstype for Webex Calling.

For å skille mellom funksjonalitet som tilbys av anropskøer kombinert med den profesjonelle lisensen i motsetning til kundestøtte, se Webex Calling-anropskø- og kundestøttefunksjonssammenligning.

Brukerklargjøring

Når du klargjør brukere i Webex, finnes det flere alternativer tilgjengelig, som alle er egnet for ulike organisasjonsbehov og miljøer:

Manuell klargjøring: Administratorer kan legge til og administrere individuelle brukere direkte i . Denne metoden er enkel, men passer best for små organisasjoner eller begrensede brukerendringer.

Masseklargjøring via CSV: For større brukerbaser kan administratorer importere og oppdatere brukere samtidig ved å laste opp CSV-filer til . Dette muliggjør effektiv administrasjon av opptil tusenvis av brukere samtidig.

Alternativer for katalogsynkronisering:
Katalogkobling: Dette er et automatisk synkroniseringsverktøy som brukes i Microsoft Active Directory-miljøer. Den synkroniserer brukerkontoer, grupper og attributter etter planen (hver time, daglig eller ukentlig). Den støtter Active Directory-oppsett for flere domener og flere skoger, og kan synkronisere profilbilder og romobjekter.

Veiviserapp for Entra ID (Azure AD): Denne metoden er utviklet for organisasjoner som bruker Microsoft Entra ID (Azure AD), og gir automatisk synkronisering av brukerkontoer og attributter i nesten sanntid direkte fra Entra ID til . Den administreres fullt ut internt og krever minimalt med oppsett.

SCIM 2.0-applikasjoner: For ikke-Microsoft-miljøer eller andre identitetsleverandører som Okta eller Duo, muliggjør SCIM-baserte synkroniseringsapper automatisk brukerklargjøring og -avklargjøring med attributttilordning og gruppesynkronisering.

Synkronisering av enhetlig CM-bruker: Dette alternativet lar deg opprette brukerkontoer basert på eksisterende sluttbrukere ved å synkronisere fra til . Dette krever at Cloud Connected UC (CCUC) kjører på de lokale klyngene. Det anbefales imidlertid generelt å synkronisere brukere fra en sentralisert skykatalog som Entra ID i stedet for direkte fra .

API-klargjøring: Offentlige API-er (People, SCIM 2.0) kan brukes til å klargjøre brukere. Hovedfordelen med å bruke API-er er muligheten til å integrere brukerprovisjonering med andre bedriftssystemer.
Tabell 6. Alternativer for brukerklargjøring for
Provisioneringsmetode Beskrivelse Fordeler Ulemper
Håndbok Create/manage brukere individuelt i Enkelt for få brukere; ingen infrastruktur nødvendig Ikke skalerbar; tidkrevende for mange brukere
Masse (CSV-fil) Import/update brukere i bulk via CSV i Effektiv for grupper; ingen koding nødvendig Manuell CSV-forberedelse; mindre dynamisk
Mennesker og SCIM 2.0 API Programmatisk brukeradministrasjon via Webex API-er Fleksibel; støtter automatisering og integrasjon Krever utvikling og infrastruktur
Katalogsynkronisering Automatisk synkronisering fra AD, Entra ID, SCIM-apper og Unified CM Automatiserer livssyklusen; støtter filtrering og kartlegging Kompleksitet i oppsettet: Noen av alternativene har begrensede funksjoner eller krever infrastruktur
Denne oversikten og tabellen gjenspeiler de viktigste alternativene for brukerklargjøring, fordelene og begrensningene deres, slik at du kan velge den beste tilnærmingen for organisasjonens behov.

Brukergrupper

Brukergruppeadministrasjon lar administratorer organisere brukere i grupper for effektiv masseadministrasjon av lisenser, innstillinger og ressurser. Grupper bidrar til å effektivisere administrasjonen ved å bruke policyer, lisenser og innstillingsmaler på flere brukere samtidig, i stedet for å administrere brukere individuelt.

Brukergruppeadministrasjon tilbyr flere fordeler, inkludert:

Forenklet administrasjon: Administrer lisenser, innstillinger og retningslinjer for flere brukere samtidig.

Konsistens: Bruk ensartede innstillinger og lisenser på tvers av brukere i samme gruppe.

Skalerbarhet: Støtter opptil 250 000 medlemmer per gruppe.

Integrasjon: Synkroniser grupper fra Microsoft Entra ID (Azure AD) eller Active Directory for automatisert bruker- og gruppeadministrasjon.

Fleksibilitet: Opprett lokale grupper eller synkroniser sikkerhetsgrupper; administrer gruppemedlemskap manuelt eller via CSV-filer.

Ressursallokering: Kontroller tilgang til innebygde apper og tjenester basert på gruppemedlemskap.

De viktigste bruksområdene for brukergrupper ved provisjonering er:

Lisenstildelinger: Tilordne lisenser til grupper for automatisk å klargjøre tjenester som anrop, møter, meldinger eller hybridtjenester til gruppemedlemmer.

Innstillingsmaler: Bruk samlinger av tjenesteinnstillinger (f.eks. meldinger, møter, anrop) på grupper for en konsistent brukeropplevelse.

Massebrukeradministrasjon: Legg til eller fjern brukere samtidig via CSV-filer eller katalogsynkronisering.

Automatisering og integrasjon: Bruk API-er eller katalogsynkronisering for automatisert administrasjon av bruker- og gruppelivsykluser.

Tabellen nedenfor oppsummerer de ulike alternativene for å administrere brukergrupper og gruppeadministrasjon i .
Tabell 7. Alternativer for å administrere grupper og gruppemedlemskap
Alternativ Beskrivelse Fordeler Ulemper

gruppeklargjøring (grupper) Opprett og administrer grupper direkte i . Add/remove medlemmer manuelt eller via CSV. Full kontroll over gruppemedlemskap
Umiddelbar anvendelse av lisenser og maler
Enkelt å opprette og redigere grupper Manuelle oppdateringer kreves
Risiko for feil ved manuelle CSV-opplastinger
Ingen automatisk synkronisering med eksterne kataloger

Synkroniserte grupper fra Entra ID (Azure AD) eller Active Directory Synkroniser sikkerhetsgrupper og medlemskap automatisk fra eksterne katalogtjenester. Automatisert synkronisering reduserer manuelt arbeid
Sikrer samsvar med bedriftskatalogen
Støtter store organisasjoner
Kan ikke redigere gruppemedlemskap i
Synkroniseringsforsinkelse på opptil 12 timer
Nestede grupper krever manuelt valg

Grupper og SCIM 2.0 API (Grupper) Bruk Grupper eller SCIM 2.0 API for programmatisk gruppe- og medlemskapsadministrasjon Automatisering og integrasjon med andre systemer
Skalerbar for store eller komplekse miljøer
Krever utviklingsinnsats
Kompleksitet avhenger av API-bruk

Selv om synkroniserte grupper sikrer konsistens og tilbyr ett enkelt administrasjonspunkt, er en hybrid tilnærming som kombinerer synkroniserte grupper og grupper (enten administrert i kontrollhuben eller via API-er) mulig. Så kan for eksempel grupper for lisenstildeling være synkroniserte grupper, og et separat sett med grupper kan brukes til å tilordne bruker- og kallmaler.

Denne omfattende tilnærmingen til administrasjon av brukergrupper gjør det mulig for organisasjoner å administrere brukerlisenser, innstillinger og retningslinjer effektivt, og dermed sikre konsistente og skalerbare samarbeidsopplevelser.

Anbefalt tilnærming ved migrering fra til

Den primære datakilden for brukere er databasen, som inneholder sluttbrukerinformasjon. er imidlertid vanligvis ikke den autoritative kilden for brukeridentitetsadministrasjon, og enda viktigere, vil bli lagt ned ved slutten av overgangen og er derfor utelukket som en langsiktig autoritativ kilde for identitetsinformasjon.

Cisco anbefaler å bruke en sentralisert skykatalog, for eksempel Microsoft Entra ID (Azure AD), som den eneste sannhetskilden for brukeridentiteter. Synkronisering av brukere fra Entra ID sikrer konsistens, forenkler administrasjon og støtter funksjoner for enkel pålogging (SSO).

For å sikre at alle brukere på plattformen også er til stede i Entra ID, bør organisasjoner bekrefte at brukerkontoene samsvarer med kontoene i Entra ID. Dette kan gjøres ved å eksportere brukerlister fra og sammenligne dem med Entra ID-brukerlister.

Oppsummert er den anbefalte klargjøringsmetoden å synkronisere brukere fra Microsoft Entra ID (Azure AD) til Webex ved hjelp av Azure AD-veiviseren eller SCIM-apper. Manuell og CSV-bulkprovisjonering er tilgjengelige som tilleggsmetoder, men er mindre skalerbare og mer feilutsatte for store organisasjoner. Å sørge for at Entra ID er den autoritative kilden og at alle brukere finnes i Entra ID er avgjørende for en vellykket migrering og en konsistent brukeropplevelse på tvers av miljøer.

Overgang fra en lokal katalogtjeneste, som Active Directory, til en skybasert katalogtjeneste, som Entra ID (Azure ID), er uavhengig av den kallende overgangen. Cisco anbefaler å fullføre overgangen til en skybasert katalogtjeneste før du starter den kallende overgangen.

Utforming av brukergrupper

Etter at du har overført bedriftskatalogen fra lokalt til skyen, samler du inn de nødvendige brukergruppene drevet av lisens- og funksjonsmalkrav. For hvert gruppedokument:

Gruppenavn: gruppens unike navn.

Lisenser: lisenser som skal tilordnes denne gruppen (hvis noen) og omfang (skal lisenser tilordnes eksisterende brukere eller bare nye brukere)

Innstillingsmaler: Webex-app og brukeranropsmaler.

Katalogsynkronisering: Vil denne gruppen bli synkronisert fra bedriftskatalogen, eller er dette en lokal Webex-gruppe som er klargjort i Control Hub eller via et API.

Beskrivelse: hvordan skal denne gruppen brukes, og hvilke brukere bør være medlemmer av denne gruppen

Disse detaljene vil bli brukt senere i implementeringsfasen til å opprette lokale grupper eller grupper i bedriftskatalogen og administrere gruppemedlemskap for brukere.

Enkel pålogging (SSO)

Cisco anbefaler bruk av SSO for brukerautentisering. Bruk av SSO har noen overbevisende fordeler, inkludert:

Forenklet brukerautentisering: Brukere kan logge på én gang med bedriftens legitimasjon (f.eks. fra Azure ID) for å få tilgang til andre integrerte applikasjoner, noe som eliminerer behovet for flere passord og reduserer behovet for påloggingsforespørsler. Dette forbedrer sikkerheten ved å sikre at bedriftspassord aldri lagres eller overføres etter autentisering.

Forenklet brukeradministrasjon: Automatiserer opprettelse, oppdateringer og deaktivering av brukerkontoer basert på endringer i bedriftskatalogen, noe som reduserer administrative kostnader og sikrer at bare autoriserte brukere har tilgang.

Forbedret sikkerhet: SSO reduserer passordtretthet og risikoen for passordrelaterte brudd ved å sentralisere autentisering gjennom pålitelige identitetsleverandører (IdP-er).

Enkel integrering av flerfaktorautentisering (MFA): MFA kan enkelt støttes enten gjennom en Identity Access Management-løsning som Cisco Duo eller gjennom MFA-støtte for IdP-en.

Det finnes flere alternativer for å implementere SSO for tjenester:

SAML 2.0-basert SSO: Den primære protokollen som støttes for SSO-integrasjon, og muliggjør sikker utveksling av autentiseringsinformasjon mellom IdP-en og tjenesteleverandøren.

OpenID-tilkobling (OIDC): Støttes som en alternativ moderne autentiseringsprotokoll for SSO-integrasjon.

Webex-identitet: Støttes også som et identitetsleverandøralternativ.

SSO konfigureres og administreres sentralt gjennom , noe som krever utveksling av metadata mellom og den valgte IdP-en.

Etter konfigurasjon kan SSO testes før aktivering for å sikre riktig oppsett.

Cisco støtter integrasjon med flere testede og vanlige IdP-er og identitetsstyringssystemer (IAM), inkludert, men ikke begrenset til:

Cisco Duo

Okta

Microsoft Active Directory Federation Services (ADFS)

Microsoft Azure

PingFederate

ÅpenAM

F5 STOR-IP.

Disse IdP-ene er i samsvar med SAML 2.0- eller OpenID Connect-standardene og har blitt validert for kompatibilitet med Ciscos samarbeidsløsninger.

Støtte for flere IdP-er

lar organisasjoner konfigurere SSO med flere IdP-er for å imøtekomme komplekse IT-miljøer som fusjoner, oppkjøp eller desentraliserte IT-avdelinger der forskjellige grupper bruker forskjellige IdP-er. Støtte for flere IdP-er kan enten implementeres ved hjelp av funksjonen for flere IdP-er i eller gjennom integrering av et IAM-system for bedrifter som Cisco Duo.

s støtte for flere identitetsleverandører (IdP) adresserer flere viktige brukstilfeller der organisasjoner trenger fleksibel og sikker autentisering på tvers av ulike IT-miljøer:

1. Fusjoner og oppkjøp

Når selskaper fusjonerer eller oppkjøper andre, har de ofte separate IT-infrastrukturer og distinkte IdP-er som ikke kan slå seg sammen. Støtte for flere IdP-er lar brukere fra begge organisasjoner autentisere og samarbeide sikkert uten å måtte forene identitetssystemene sine umiddelbart.

2. Flere uavhengige IT-avdelinger

Store organisasjoner eller offentlige institusjoner kan ha flere uavhengige IT-avdelinger, som hver administrerer sin egen IdP. s funksjon for flere IdP-er gjør det mulig for disse avdelingene å vedlikeholde sine egne autentiseringssystemer, samtidig som brukerne får sømløs tilgang.

3. Ulike brukergrupper eller domener

Organisasjoner med ulike brukergrupper (f.eks. ansatte kontra kontraktører) eller flere e-postdomener kan konfigurere rutingsregler for å dirigere autentiseringsforespørsler til riktig IdP basert på domene- eller gruppemedlemskap. Dette støtter differensierte tilgangspolicyer og sikkerhetskontroller.

4. Støtte for ulike autentiseringsprotokoller

støtter SAML- og OpenID Connect (OIDC) IdP-er, slik at organisasjoner kan integrere ulike typer identitetsleverandører i henhold til deres eksisterende infrastruktur og sikkerhetskrav.

5. Forbedret sikkerhet og samsvar

Ved å aktivere flere IdP-er kan organisasjoner implementere sterkere autentiseringsmekanismer, inkludert flerfaktorautentisering (MFA) gjennom integrasjoner som Duo, og håndheve konsistente sikkerhetspolicyer på tvers av ulike brukerbaser.

6. Forenklet brukeropplevelse

Brukere kan autentisere seg ved hjelp av eksisterende legitimasjon fra sine respektive IdP-er, noe som gir en enhetlig påloggingsopplevelse til tross for den underliggende kompleksiteten til flere identitetssystemer.

Selv om støtte for flere IdP-er gir fleksibilitet, krever det nøye koordinering mellom sikkerhets- og identitetsteam for å opprettholde konsistente sikkerhetspolicyer og unngå potensielle sårbarheter.

Duo MFA med SSO for

Duo Access Gateway (DAG) kan autentisere brukere ved hjelp av eksisterende lokale eller skybaserte kataloger som Active Directory (AD) og OpenLDAP. Den støtter også integrasjon med andre identitetsleverandører som Microsoft ADFS, Microsoft Azure, Okta, OneLogin, CAS og Shibboleth. Denne fleksibiliteten lar organisasjoner bruke sin nåværende kataloginfrastruktur for Webex SSO med Duo MFA.

Duo fungerer som et sterkt autentiseringslag på toppen av autentiseringen av den primære katalogen. Den fungerer som en identitetsleverandør (IdP) som bruker SAML 2.0 for å håndheve tofaktorautentisering (2FA) før den gir tilgang til . Duo evaluerer bruker-, enhets- og nettverkskontekst mot konfigurerbare policyer for å tillate eller nekte tilgang, noe som forbedrer sikkerheten utover bare brukernavn og passord. Duo tilbyr også fleksible policykontroller, som å kreve MFA ved hver pålogging for noen apper og sjeldnere for andre.

Fordelene med Cisco Duo inkluderer:

Forbedret sikkerhet: Legger til phishing-resistent MFA for å beskytte tilgang, noe som reduserer risikoen fra kompromitterte passord.

Fleksible retningslinjer: Gir detaljert kontroll over autentiseringskrav per applikasjon eller brukergruppe.

Integrasjon med eksisterende kataloger: Støtter lokale AD, OpenLDAP, skykataloger og diverse SSO-leverandører, noe som minimerer endringer i infrastrukturen.

Brukervennlighet: Støtter enkel pålogging (SSO) for å redusere passordtretthet ved å la brukere logge på én gang og få sikker tilgang til flere ressurser.

Pålitelige endepunkter: Støtter enhetsklarering for klienter på Windows og macOS, noe som forbedrer sikkerhetstilstanden.

Selvbetjeningsregistrering: Innebygd registrering og duo-ledetekst forbedrer brukeropplevelsen under MFA-oppsettet.

Duo MFA med SSO utnytter eksisterende kataloger som Active Directory og OpenLDAP, eller skyidentitetsleverandører, for å autentisere brukere. Duos rolle er å tilby en sterk, policydrevet andre autentiseringsfaktor integrert gjennom SAML 2.0, som forbedrer sikkerheten samtidig som brukervennligheten opprettholdes gjennom SSO. Fordelene inkluderer forbedret sikkerhetstilstand, fleksibel håndheving av retningslinjer, sømløs integrasjon og en bedre brukeropplevelse.

Cisco anbefaler å implementere SSO for brukere. For forbedret sikkerhet anbefales integrering med Cisco Duo.

Enterprise IAM- og SSO-strategien bør implementeres før overgangen fra til .

Funksjoner

har et komplett utvalg av kjernefunksjoner som er inkludert i tjenesten. Dette inkluderer mange ringefunksjoner i bedriftsklassen som har vært tilgjengelige i mange år. Du ser kanskje ikke 100 % likhet mellom funksjoner og funksjoner, men som du kan se i figuren nedenfor, er de viktigste anropsfunksjonene tilgjengelige i .

Webex Calling-funksjoner i bedriftsklassen

I tillegg til de mange brukerfunksjonene, har den kjernefunksjoner i systemet som er inkludert i plattformen. Disse inkluderer funksjoner som automatiske svarere, samtalekøer, samtaleparkering osv. Du kan se alle tilgjengelige kjernefunksjoner i systemet under Tjeneste → Anrop → Funksjoner som vist i figur Webex Calling-kjernefunksjoner.

Webex Calling-kjernefunksjoner

Automatisk assistent

Den automatiske svareren tillater 24/7 automatisering av håndtering av innkommende anrop, som muliggjør effektiv samtalehåndtering uten behov for at en person svarer på hvert anrop.

Den automatiske svareren svarer på innkommende anrop og gir den som ringer en meny med alternativer for hvor de vil rute samtalen sin. Dette kan være til en person, en talepostkasse eller en ringetjeneste (f.eks. samtalekø). Den som ringer bruker telefonens talltastatur til å taste inn nummeret fra den automatiske svarermenyen.

Den automatiske svareren støtter følgende viktige funksjoner:

Forretnings- og ettertidstider

Ferieplan

Oppringingsmenyalternativ for å dirigere kundene dine dit de skal

Tilpass hilsener

Alternativ for å ringe etter navn

Alternativer for viderekobling av anrop

Control Hub-analyse og -rapporter.

Hvis du vil ha mer informasjon, kan du se Administrere automatiske svarere.

Samtaleparkering

Samtaleparkering gir brukere muligheten til enkelt å sette en samtale på vent slik at en annen bruker enkelt kan hente den når de er tilgjengelige til å ta den. Det frigjør også brukeren som svarte på det opprinnelige anropet til å foreta eller motta andre anrop mens samtalen er parkert.

Det finnes to typer samtaleparker tilgjengelig i :

Direkte samtaleparkering – lar enhver bruker parkere en samtale til en annen brukers internnummer eller til en internnummer for samtaleparkering, som definert av administratoren.

Samtaleparkeringsgruppe – lar en definert gruppe brukere automatisk parkere samtaler mot tilgjengelige parkeringsdestinasjoner som er definert for gruppen. Disse destinasjonene kan være gruppemedlemmenes internnumre eller internnumre for parkerte samtaler.

Basert på konfigurasjon og parkeringstype kan brukere hente anrop ved å ringe *88+><extension of parked call>, trykke på linjetasten som er knyttet til internnummeret for samtaleparkering, eller bruke en funksjonstast på IP-telefonen.

Et tilbakekallingsalternativ er tilgjengelig for å tilbakekalle en parkert samtale etter en angitt periode til brukeren som parkerte samtalen eller til en alternativ bruker.

Hvis du vil ha mer informasjon, kan du se Administrer samtaleparkering i Control Hub.

Henting av samtale

Med funksjonen for å hente anrop kan en administrator definere en gruppe brukere (medlemmer) som kan svare på et anrop til et annet medlems telefon. Dette gir en bruker muligheten til å svare på anrop når lagkameratene deres er opptatt og ikke kan svare på et innkommende anrop.

Brukerne i en gruppe må være på samme sted.

Brukere kan bruke enten eller bordtelefonen sin til å besvare en samtale.

:

Støtter visuelle og lydvarsler

Varsling om innkommende anrop

FAC-basert (ring *98) eller varsling toast samtalehenting

Varsler om innhenting av samtaler for flere linjer.

Bordtelefoner:

Varsling om innkommende anrop

Lydsignaler og visuell varsling via LED-lampen på håndsettet. 6821 støtter bare lydklokker

Når varslingstypen som er valgt i ikke er ingen

Varsler om innhenting av samtaler kun for hovedlinjer.

Hvis du vil ha mer informasjon, kan du se Konfigurere anropsmottaksgruppe

Samtalekø

inkluderer kun taleanropskøer som en del av kjernefunksjonene, og enhver bruker med en profesjonell lisens kan være en del av en anropskø, agent eller veileder. Denne funksjonen lar brukere effektivt kommunisere med kunder. Anropskøer støtter et delsett av noen av kjernefunksjonene i kundesenteret, som talekøer, tilbakeringing, ferdighets- eller prioritetsruting, køhåndtering av agenter, analyser, rapportering osv.

Ciscos integrering med Microsoft Teams lar agenter få tilgang til samtaler og funksjoner i anropskøen direkte fra Microsoft Teams-klienten.

Samtalekøer støtter følgende viktige funksjoner:

Hilsener og meldinger (velkomst, trøst, hvisking osv.)

Hold musikken

Tilbakeringing

Regler for køruting (nattruting, helligdager, videresending)

Agentkø login/logout

Administrasjon av agentkøstatus

eller bordtelefonstøtte

Veilederagent, ring overvåk, veilede, bryte inn eller ta over via funksjonstilgangskoder (FAC-er)

(administratortilgang) for:

køhåndtering

Agent- og køanalyse og rapportering

Kø-, agent- og veilederadministrasjon.

Hvis du vil ha mer informasjon, kan du se Konfigurere anropskø.

har en tilleggsfunksjon for Customer Assist som gir ekstra muligheter for samtalekø og gir agenter og veiledere en bedre brukeropplevelse i . For en sammenligning av funksjonene for samtalekø og kundestøtte, se Sammenligning av Webex Calling-funksjoner for samtalekø og kundestøtte.

Hunt Group

Søkegrupper tillater ruting av innkommende anrop til en bestemt gruppe brukere gjennom et forhåndsbestemt samtalerutingsmønster. Dette sikrer at anrop blir besvart av riktig gruppe brukere eller sendt til en telefonsvarer for oppfølging.

En stor forskjell mellom søkegrupper og samtalekøer er at samtaler ikke settes i kø i en søkegruppe, så hvis ingen brukere i søkegruppen er tilgjengelige til å svare på anropet, vil det bli koblet fra, sendt til mobilsvar eller videresendt til et annet nummer (bruker eller tjeneste).

Hvis du vil ha mer informasjon, kan du se Administrere søkegrupper i Kontrollhub.

Driftsmoduser

Funksjonen Driftsmoduser lar bedrifter effektivt rute samtaler til ulike destinasjoner (brukere, talepost, ringetjenester som en samtalekø). Hvor og når en samtale rutes er basert på en tidsplan for døgnet og ukedagen, og enhver bruker kan autoriseres til å administrere disse modusene (planene) for å kontrollere endringer i samtalerutingen.

Som et eksempel kan anrop til en anropskø rutes til en annen anropskø med agenter i en annen tidssone for å svare på anrop etter stengetid, i løpet av åpningstiden rutes til de lokale agentene, og i løpet av helligdager rutes til telefonsvarer for oppfølging etter at agenter kommer tilbake til kontoret.

En autorisert bruker kan bytte mellom disse ulike viderekoblingsscenarioene (modusene) hvis de trenger å endre hvor innkommende anrop rutes i en viss periode. Disse brukerne kan administrere modusene via sine 6800/7800/8800 MPP-telefoner, 9800-telefoner eller i brukerhuben på Administrer moduser.

Hvis du vil ha mer informasjon, kan du se Anropsruting basert på driftsmoduser i Webex Calling.

Personsøkergruppe

Personsøkergrupper lar brukere foreta et enveisoppringing for å sende en lydmelding til en gruppe brukere. Hver gruppe kan inneholde opptil 75 målbrukere and/or arbeidsområder som nås ved å ringe et forhåndsdefinert nummer eller en internnummer.

Når en bruker ringer en personsøkergruppe, foretas et samtidig anrop til alle de tildelte målene i gruppen, hvoretter den som ringer kan snakke inn meldingene sine og legge på når de er ferdige.

Hvis du vil ha mer informasjon, kan du se Konfigurere en personsøkergruppe i Control Hub.

Opptak

støtter opptak av samtaler som er foretatt eller mottatt av en bruker. Dette kan være nødvendig av hensyn til kvalitet, sikring, sikkerhet eller opplæring. Som standard tas samtaler opp i , men andre tredjepartsleverandører av opptak kan også brukes hvis andre opptaksfunksjoner eller samsvars- og forskriftskrav er påkrevd.

Når den brukes som opptaksplattform, administreres alle innspilte samtaler i . Fullstendige administratorer med rollen som samsvarsansvarlig kan spille av og laste ned opptakene. Uten rollen som samsvarsansvarlig kan administratoren bare slette opptakene.

Hvis du vil ha mer informasjon om denne funksjonen og en liste over tredjepartsopptak, kan du se Administrer samtaleopptak for Webex Calling.

Enkeltnummer rekkevidde

Rekkevidde for ett nummer tillater at anrop til en brukers telefonnummer ringer til flere enheter. Dette kan inkludere andre bordtelefoner så vel som mobiltelefoner. Samtaler kan også foretas fra disse enhetene, og brukere kan pushe og trekke samtaler mellom dem.

Hvis du vil ha mer informasjon om denne funksjonen og hvordan en administrator konfigurerer den i Konfigurer kontakt med ett enkelt nummer (kontor hvor som helst).

Hvis du vil ha mer informasjon om hvordan en bruker kan administrere og konfigurere denne funksjonen for seg selv i Webex-brukerhub (portal), kan du se Konfigurere rekkevidde for ett enkelt nummer (kontor hvor som helst).

Talepostgruppe

Talepostgrupper tillater en delt talepostkasse som kan tilordnes en bruker eller en funksjon for anropsruting. Noen av grunnene til at en talepostgruppe kan være nødvendig er:

Generell talepost for en avdeling eller arbeidsgruppe

Legg til talepostalternativer i en automatisk svarer eller søkegruppe

Slik sender du overløpsanrop fra en samtalekø

Brukere som bare trenger en telefonsvarer.

Hvis du vil ha mer informasjon, kan du se Administrer en delt talepost og innkommende faksboks for Webex Calling.

Attendant Console er oppført på siden Samtalefunksjoner i Webex, men det er en tilleggsfunksjon som krever kjøp av Attendant Console-lisensen for å bruke den.

Hvis du vil ha mer informasjon, kan du se Kom i gang med Attendant-konsollen.

Hvis du vil ha informasjon om alle funksjoner, inkludert noen tilleggsfunksjoner, kan du se Funksjoner tilgjengelig etter lisenstype for Webex Calling.

Tabell 1. Informasjon som skal samles inn for hvert sted
Informasjon	Kommentar
Utvidelsesområde(r)	Hvert sted kan ha utvidelser som starter med forskjellige sifre. Ett siffer må være avsatt for styringssifferet for oppringing mellom lokasjoner (for eksempel 8) og ett for styringssifferet for PSTN (for eksempel 9). Ingen utvidelsesområder kan starte med noen av disse to sifrene. Alle forlengelsesområder for alle lokasjoner må være like lange.
DID-område(r)	-
PSTN-styringssiffer	-
Nettstedskode	Alle nettstedskoder for alle steder må være unike og ha samme lengde.
Hovednummer	Når du oppretter en lokasjon, må to DID-er klargjøres. Ett som hovednummer (for eksempel for å bli tilordnet en automatisk svartjeneste) og ett for telefonsvarerportalen. Tildel én DID for talepostnummeret.
Telefonsvarernummer
Antall lisenser	Nødvendige lisenser etter type, inkludert Standard, Profesjonell, Arbeidsområde, Ruteliste, Utgående anropsavtale.
Samtidige samtaler i den travle timen	Summen av samtidige samtaler mellom enheter og mellom enheter og den lokale gatewayen (PSTN og samtaler til enheter). Trenger å bestemme nødvendig båndbredde for internettilgang.
Land	-
Tidssone	-
Språk	-
Kontakt (navn, telefon, e-post)	-
Adresse (gateadresse, by, stat, postnummer)	-
Fysisk utsendelsessted for nødetater for endepunkter	Enhetsadresse som kan sendes til nødanrop inkluderer vanligvis følgende: bygningsadresse, bygningsadresse + etasjenummer, bygningsadresse + leilighetsnummer eller bygningsadresse + etasjenummer + office/cubical tall.
Unik fysisk nettverksplassering per enhet for nødetater	Fysisk nettverksplassering for nødanrop inkluderer vanligvis følgende: bryter / switchport for kablede enheter, trådløst tilgangspunkt (AP) Basic Service Set Identifiers (BSSID-er) for trådløst tilkoblede enheter, and/or Lokale IP-delnett for endepunktenheter.

Tabell 2. Eksempel på bedriftsnummerering
Nettsted	Utvidelsesområde	Nettstedskode	Bedriftsserien
NYC	2XXX	202	8 202 2XXX
SFO	3XXX	203	8 203 3XXX
RTP	2XXX	204	8 204 2XXX

Tabell 3. Forlengelsesområder med fast lengde
Nettsted	Utvidelsesområde	Utvidelser	Nettstedskode	Bedriftsserien
NYC	2XXX	2XXX	202	8 202 2XXX
SFO	8XXX	7XXX	203	8 203 7XXX
RTP	1XX	11XX	204	8 204 11XX

Tabell 4. Overgang til syvsifret oppringing

Nettsted	Utvidelser	Nettstedskode	Bedriftsserien	Nettstedsode	Enterprise angel
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

Tabell 5. Alternativer for brukerklargjøring – sammendrag
Tildelingsmetode	Fordeler	Ulemper
Manuell gjennom	Enkelt for få brukere. Gir presis og detaljert kontroll over lisenstildeling.	Ikke skalerbar, tidkrevende Utsatt for menneskelige feil ved manuell inntasting.
Automatiske lisensmaler	Skalerbar Reduserer manuelle feil Kan brukes på nye og eksisterende brukere.	Krever gyldige telefonnumre og steder. Mer komplekst å sette opp Krever også brukergrupper per brukergruppe med tilsvarende lisenskrav.
Masseopplasting av CSV	Effektiv for store brukergrupper Tillater samtidig tildeling av lisenser, telefonnumre og internnumre.	Krever nøye CSV-formatering Mulighet for feil hvis telefonnumre eller internnumre mangler eller er feil.
API-basert tildeling	Automatiserbar, fleksibel. Tillater samtidig tildeling av lisenser, telefonnumre og internnumre.	Krever utvikling og API-kunnskap.

Tabell 6. Alternativer for brukerklargjøring for
Provisioneringsmetode	Beskrivelse	Fordeler	Ulemper
Håndbok	Create/manage brukere individuelt i	Enkelt for få brukere; ingen infrastruktur nødvendig	Ikke skalerbar; tidkrevende for mange brukere
Masse (CSV-fil)	Import/update brukere i bulk via CSV i	Effektiv for grupper; ingen koding nødvendig	Manuell CSV-forberedelse; mindre dynamisk
Mennesker og SCIM 2.0 API	Programmatisk brukeradministrasjon via Webex API-er	Fleksibel; støtter automatisering og integrasjon	Krever utvikling og infrastruktur
Katalogsynkronisering	Automatisk synkronisering fra AD, Entra ID, SCIM-apper og Unified CM	Automatiserer livssyklusen; støtter filtrering og kartlegging	Kompleksitet i oppsettet: Noen av alternativene har begrensede funksjoner eller krever infrastruktur

Tabell 7. Alternativer for å administrere grupper og gruppemedlemskap
Alternativ	Beskrivelse	Fordeler	Ulemper
gruppeklargjøring (grupper)	Opprett og administrer grupper direkte i . Add/remove medlemmer manuelt eller via CSV.	Full kontroll over gruppemedlemskap Umiddelbar anvendelse av lisenser og maler Enkelt å opprette og redigere grupper	Manuelle oppdateringer kreves Risiko for feil ved manuelle CSV-opplastinger Ingen automatisk synkronisering med eksterne kataloger
Synkroniserte grupper fra Entra ID (Azure AD) eller Active Directory	Synkroniser sikkerhetsgrupper og medlemskap automatisk fra eksterne katalogtjenester.	Automatisert synkronisering reduserer manuelt arbeid Sikrer samsvar med bedriftskatalogen Støtter store organisasjoner	Kan ikke redigere gruppemedlemskap i Synkroniseringsforsinkelse på opptil 12 timer Nestede grupper krever manuelt valg
Grupper og SCIM 2.0 API (Grupper)	Bruk Grupper eller SCIM 2.0 API for programmatisk gruppe- og medlemskapsadministrasjon	Automatisering og integrasjon med andre systemer Skalerbar for store eller komplekse miljøer	Krever utviklingsinnsats Kompleksitet avhenger av API-bruk

Implementer

Nettverksberedskap

Første oppsett

Domeneverifisering

Gjør krav på (konverter) eksisterende brukere

Konfigurer og test katalogsynkronisering

Konfigurer og test enkel pålogging (SSO)

Anskaffe, klargjøre og verifisere lisenser

Innstillinger for Webex Calling-tjenesten

Pilotmigrering

Anskaffe PSTN

Konfigurer lokasjoner

Integrasjon med lokal samtalekontroll

Migrer brukere i grupper

Arbeidsområder

Klargjøringsenheter

Konfigurer funksjoner

Aksepttesting

Nettverksberedskap

Det første trinnet i overgangen til er å sikre pålitelig og sikker internettforbindelse mellom det lokale nettverket og skyen.

Siden de fleste organisasjoner kobler seg til internett gjennom én eller flere brannmurer eller sikkerhetsenheter, er det viktig å validere at de nødvendige trafikkflytene støttes.

Nettverks- og sikkerhetsadministratorer må forstå disse flytene med tanke på:

Retning (inngående vs. utgående)

Protokoller (Eksempel - SIP TLS, SRTP, HTTPS)

IP-adresseområder brukt av tjenester

Portnumre som må åpnes eller tillates.

Dette sikrer at bedriftens brannmurer, NAT-enheter og annen nettverksinfrastruktur er riktig konfigurert for å håndtere trafikk, samtidig som bedriftens sikkerhetspolicyer opprettholdes.

For informasjon om nødvendige flyter, inkludert IP-adresse, porter og protokoller, se Portreferanseinformasjon for Webex Calling. Bruk denne informasjonen til å konfigurere brannmuren, proxy-tjenere og annen nettverksinfrastruktur i den eksisterende distribusjonen for å aktivere nettverksflyter.

Desentralisert internettutbrudd fra hver filial eller lokasjon er den anbefalte tilnærmingen for skybaserte samarbeidstjenester som . Ved å tillate trafikk å gå ut lokalt, gjør denne modellen følgende:

Reduserer tur-retur-forsinkelse og jitter, noe som forbedrer den generelle samtalekvaliteten

Skalerer effektivt etter hvert som flere brukere og nettsteder går over til

Fungerer sømløst med SD-WAN, som dynamisk kan rute økter til nærmeste skytilkoblingspunkt for optimal ytelse

Lar sporing av brukerposisjon basert på deres offentlige IP-adresse, noe som hjelper med analyse av mediebaner og feilsøking.

I tillegg må organisasjoner sørge for tilstrekkelig internettbåndbredde på hvert sted. Båndbredden bør dimensjoneres basert på forventet antall samtidige samtaler, den valgte kodeken (f.eks. Opus eller G.711), pluss overhead for signalering, retransmisjoner og vekst. Dette samsvarer med forberedelsesfasen i PPDIO-livssyklusen og etablerer et solid grunnlag for migrering.

Første oppsett

Den innledende oppsettdelen i implementeringsfasen av utrullingen er grunnleggende for å etablere et godt strukturert og håndterbart skyanropsmiljø. Denne fasen omfatter kritiske oppgaver som å sette opp organisasjonen, anskaffe og tildele lisenser, og verifisere og gjøre krav på bedriftens domener for å sikre riktig brukeradministrasjon og sikkerhet. I tillegg inkluderer den klargjøring av lisensmaler for å automatisere tildeling av brukerlisenser, konfigurering av enkel pålogging (SSO) for å effektivisere brukerautentisering og forbedre sikkerheten, og justering av tjeneste- og klientinnstillinger for å samsvare med organisasjonens retningslinjer og brukerbehov. Ved å fullføre disse innledende oppsettaktivitetene sikrer du at miljøet er riktig konfigurert for skalerbarhet, sikkerhet og en sømløs brukeropplevelse, noe som legger grunnlaget for påfølgende utrullings- og driftsfaser.

Domeneverifisering

For å kunne identifisere brukere som er registrert med bedriftens e-postdomener på , er det viktig å bekrefte domenene dine. Uten domeneverifisering vil brukere bli tilordnet en forbrukerorganisasjon, noe som kompliserer brukeradministrasjonen for bedriften din. Domeneverifisering er et obligatorisk trinn som gjør at organisasjonen din kan gjøre krav på og administrere disse brukerne effektivt.

Sørg for at alle domener som er knyttet til brukernes e-postadresser, er bekreftet. Domeneverifisering er ikke eksklusiv; det samme domenet kan verifiseres på tvers av flere organisasjoner.

Hvis du vil ha mer informasjon om hvordan du administrerer domener, kan du se Administrer domenene dine.

Gjør krav på (konverter) eksisterende brukere

Etter at du har bekreftet domenene dine, kan du fortsette å gjøre krav på brukere som har registrert seg for bruk av bedriftens e-postdomener i organisasjonen din. Denne prosessen konsoliderer alle brukere under én organisasjonsparaply, noe som muliggjør sentralisert administrasjon og strømlinjeformet administrasjon. Ved å gjøre krav på disse brukerne sikrer du at bedriften din har full kontroll over brukerkontoer, slik at du kan tilordne nødvendige lisenser, konfigurere tjenester og tilby nødvendig støtte effektivt. Denne enhetlige administrasjonsmetoden forbedrer sikkerheten, forenkler brukerklargjøring og sikrer jevn tilgang til tjenester på tvers av organisasjonen. Å gjøre krav på brukere forhindrer også at de administreres i eksterne eller forbrukerorganisasjoner, og dermed opprettholdes organisasjonens integritet og kontroll over samarbeidsressurser.

Hvis du vil ha mer informasjon om hvordan du gjør krav på brukere, kan du se Gjør krav på brukere til organisasjonen din (konvertere) brukere.

Konfigurer og test katalogsynkronisering

For å muliggjøre sømløs bruker- og gruppeadministrasjon kan du synkronisere brukere og grupper fra bedriftskatalogen din, enten Microsoft Entra ID (tidligere Azure AD) eller Microsoft Active Directory (AD), til . Denne prosessen sikrer at brukeridentiteter og gruppemedlemskap vedlikeholdes konsekvent på tvers av miljøet ditt.

For organisasjoner som implementerer fasede utrullinger, er det avgjørende å kontrollere og begrense omfanget av synkronisering under de første utrullingene. Dette minimerer risikoen for utilsiktede endringer og muliggjør målrettet testing før bredere adopsjon.

Den mest effektive metoden for å filtrere hvilke brukere som synkroniseres, er å utnytte medlemskap i kataloggrupper:

1
Opprett en dedikert synkroniseringsgruppe: I bedriftskatalogen din (Microsoft Entra ID eller AD) oppretter du en sikkerhetsgruppe spesielt for synkronisering (for eksempel synkroniseringsgruppe).

2
Fyll gruppen med målbrukere: Legg bare til brukerne du vil synkronisere (for eksempel en testgruppe i pilotfasen) i denne gruppen. Dette lar deg kontrollere nøye hvem som er inkludert i synkroniseringsprosessen.

3
Konfigurer synkroniseringsavtalen med gruppebasert filtrering: Når du konfigurerer synkroniseringsavtalen i Directory Connector eller Entra ID-klargjøring, konfigurerer du omfanget til å bare inkludere brukere som er medlemmer av den angitte gruppen.

For Microsoft Entra ID kan du bruke gruppebaserte tildelinger i klargjøringsinnstillingene.

For AD kan du definere et LDAP-filter til å bare inkludere brukere som tilhører den angitte gruppen.

4
Utvid gruppen etter behov: Etter hvert som du går videre til bredere distribusjonsfaser, legger du ganske enkelt til flere brukere eller grupper i synkroniseringsgruppen. Synkroniseringsområdet vil automatisk utvides til å inkludere disse brukerne, noe som muliggjør kontrollert og gradvis utrulling.

Eksempel på implementeringstrinn:

I aktiv katalog:

Opprett en sikkerhetsgruppe med navnet synkroniseringsgruppe.

Legg til de ønskede pilotbrukerne i denne gruppen.

Konfigurer Directory Connector med et LDAP-filter, for eksempel: (memberOf=CN=Webex Synkroniser Group,OU=Groups,DC=yourdomain,DC=com).

I Microsofts entra-ID:

Opprett en gruppe med navnet synkroniseringsgruppe

Tilordne gruppen til i Entra IDs klargjøringsinnstillinger

Bare brukere i denne gruppen vil bli tildelt .

Test alltid gruppebasert synkronisering i et ikke-produksjonsmiljø før du bruker den på hele organisasjonen.

Gjennomgå gruppemedlemskapet regelmessig for å sikre at bare autoriserte brukere synkroniseres

For løpende administrasjon, automatiser oppdateringer av gruppemedlemskap basert på forretningsregler eller HR-systemer hvis mulig.

Referanser:

Synkroniser Entra ID-brukere med Control Hub

Konfigurer Entra ID Wizard-appen i Control Hub

Katalogkobling

Konfigurer og test enkel pålogging (SSO)

Enkel pålogging (SSO) forbedrer sikkerheten og forenkler brukertilgang ved å la brukere autentisere én gang med bedriftens legitimasjon og få sømløs tilgang til . støtter SSO-integrasjon med SAML 2.0-kompatible IdP-er, inkludert Microsoft Entra ID (tidligere Azure AD), Active Directory (AD)-fødererte løsninger og diverse tredjeparts IdP-er.

På dette tidspunktet bør det designet SSO-oppsettet implementeres og testes.

Referanser:

Integrering av enkel pålogging i kontrollhub

konfigurere enkel pålogging for WebEx-administrasjon

Konfigurer enkel pålogging med Microsoft Entra ID

SSO med flere IdP-er

Administrer SSO ved integrering i Control Hub

Anskaffe, klargjøre og verifisere lisenser

Som en del av det første oppsettet for , er det viktig å anskaffe, klargjøre og verifisere de nødvendige lisensene for å aktivere og administrere tjenester effektivt. Anskaffelsesprosessen innebærer å velge lisenstyper basert på brukerroller og arbeidsbelastninger, for eksempel Professional-, Standard- og Workspace-lisenser. Lisenser genereres og klargjøres via Ciscos programvareplattformer eller gjennom partnere. Etter anskaffelse og klargjøring må riktige lisenstantall bekreftes i . Denne prosessen sikrer at organisasjonen har de riktige lisensene aktivert og klare til bruk i utrullingen.

Som en del av det første lisensieringsoppsettet i , er det viktig å konfigurere organisasjonsbasert automatisk lisensiering for å effektivisere lisenstildeling for nye brukere. Dette oppsettet gjør at lisenser automatisk tildeles når brukere legges til i organisasjonen, noe som eliminerer behovet for manuell lisenstildeling. Når du konfigurerer automatisk lisensiering på organisasjonsnivå, velger du tjenestene som skal tilordnes og definerer omfanget, for eksempel å bruke lisenser bare på fremtidige brukere eller inkludere eksisterende brukere også.

Hvis distribusjonsplanen din i stedet innebærer bruk av automatisk lisensiering på gruppenivå, kan du velge å ikke tildele lisenser på organisasjonsnivå for å unngå konflikter eller dupliserte lisenstildelinger. Med automatisk lisensiering på gruppenivå tildeles lisenser basert på gruppemedlemskap. Brukere i flere grupper mottar lisenser fra alle gjeldende gruppetildelinger.

Gruppebasert lisenstildelingskonfigurasjon må utføres etter at katalogsynkroniseringen er fullført, slik at synkroniserte grupper finnes og kan brukes til lisenstildeling.

Mer spesifikt krever automatisk lisenstildeling ytterligere klargjøringsdetaljer, for eksempel brukerplassering og telefonnummertildeling. Brukerens jobbtelefonnummer må være i +E.164 format, forhåndsklargjort og tilordnet en gyldig plassering for at lisensen skal aktiveres automatisk. Hvis disse betingelsene ikke er oppfylt, vil ikke brukeren bli tildelt tjenester automatisk, og det kan være nødvendig med manuell inngripen.

Kort sagt, konfigurer organisasjonsbasert automatisk lisensiering for nye brukere hvis du ønsker en bred, organisasjonsomfattende lisenstildeling. Hvis du foretrekker mer detaljert kontroll eller har forskjellige lisensbehov per gruppe, konfigurer automatisk lisensiering på gruppenivå og unngå å tildele lisenser på organisasjonsnivå for å forhindre overlapping og sikre riktig lisensadministrasjon.

Innstillinger for Webex Calling-tjenesten

Det er viktig å gjennomføre en omfattende gjennomgang og konfigurasjon av de globale tjenesteinnstillingene i .

Begynn med å gå inn på og navigere til innstillingsdelen. Undersøk nøye hvert konfigurerbare alternativ, inkludert, men ikke begrenset til, konfigurasjon av intern oppringing, parametere for nødanrop, retningslinjer for anropsruting, administrasjon av talepost og standardinnstillinger for enheten.

Juster disse globale innstillingene slik at de gjenspeiler organisasjonens retningslinjer og designbeslutninger.

Også oppsettinnstillinger og bruker- og appmaler.

Pilotmigrering

I implementeringsfasen representerer det å gjennomføre en pilotmigrering en kritisk milepæl i valideringen av overgangen fra til . Denne piloten innebærer å klargjøre et representativt delsett av brukere på tvers av ett eller flere steder på plattformen, og sikre at den valgte populasjonen gjenspeiler ulike brukstilfeller og organisasjonsroller. Parallelt med brukermigrering må viktige samarbeidstjenester, inkludert telefonsvarer, automatiske svarere, anropskøer og søkegrupper, overføres til tilsvarende tjenester for å opprettholde forretningskontinuitet og tjenestefunksjonalitet.

Pilotmigreringen bør utnytte den samme kombinasjonen av Cisco-leverte verktøy og tredjeparts migreringsverktøy som er planlagt for den bredere organisasjonsdistribusjonen, og sikre at prosessene, automatiseringsarbeidsflytene og integrasjonspunktene valideres grundig under representative forhold.

Hovedmålene med denne pilotutplasseringen er todelt: for det første å validere og forbedre de komplette overgangsprosessene, inkludert arbeidsflyter for brukerklargjøring, prosedyrer for datamigrering og konfigurasjoner av endepunkter; og for det andre å verifisere funksjonaliteten til migrerte tjenester under reelle driftsforhold.

Denne faseinndelte tilnærmingen lar prosjektteamet identifisere og utbedre eventuelle tekniske eller prosedyremessige problemer i et kontrollert miljø, samle tilbakemeldinger fra brukere om den nye plattformopplevelsen, vurdere effektiviteten til utvalgte migreringsverktøy og etablere tillit til migreringsmetodikken før de fortsetter med bredere organisatorisk utrulling.

Innsikten som er oppnådd i løpet av denne pilotfasen er avgjørende for å optimalisere påfølgende migreringsbølger og sikre en smidig og risikoredusert overgang for hele bedriften.

Anskaffe PSTN

For å anskaffe PSTN-tjenester for , velg først et PSTN-tilkoblingsalternativ i .

Hvis en organisasjon planlegger å opprettholde hybrid dobbel samtalekontroll ( fase 1 i figur Faset overgang til samtale: Hybrid og sky) enten midlertidig eller på ubestemt tid, må de distribuere én eller flere lokale gatewayer for lokale PSTN for å tillate anrop mellom og endepunkter.

Hvis en fullstendig overgang ( fase 2) til skyen er det endelige målet, inkludert PSTN, vil enten en Cisco-anropsavtale eller et Cloud Connect-alternativ være nødvendig for PSTN.

Samarbeid med den valgte leverandøren for å bestille og portere telefonnumre før du konfigurerer dem i . Det er kun mulig å bestille telefonnumre eller igangsette portbestillinger required/possible for lokale PSTN og Cloud Connect for . For Cisco Calling Plans startes bestilling og portering fra Control Hub så snart plasseringen er opprettet, og i land der Cisco Calling Plan er tilgjengelig. Hvis du vil ha mer informasjon om Cisco Calling-abonnementer, kan du se Komme i gang med Cisco-abonnementene.

Som en del av PSTN-implementeringen må du sørge for at leverandøren din har aktivert både innkommende og utgående PSTN-tjenester for din lokasjon. I tillegg bør du utføre testanrop for å bekrefte at anropene rutes riktig gjennom den valgte PSTN-tilkoblingen.

Konfigurer lokasjoner

Før du legger til brukere og enheter i , må du klargjøre anropssteder. For hvert sted må det oppgis en gyldig gateadresse. I USA og Canada valideres og brukes denne adressen av plattformen til å sende PIDF-LO-posisjonsinformasjon for nødanrop.

Når du konfigurerer steder som bruker lokalt PSTN, må du konfigurere de lokale gatewayene deretter. I må en trunk og en rutegruppe opprettes for hver lokale gateway, og rutegruppen tilordnes deretter som PSTN-valg for lokasjonen. Cisco anbefaler på det sterkeste at du alltid velger en rutegruppe som PSTN-valg, da denne tilnærmingen lar deg enkelt legge til flere trunker i fremtiden, noe som støtter både skalerbarhet og redundans. Cisco anbefaler også å aktivere dobbel identitet og P-Charge-Info-støtte på alle PSTN-trunker, siden dette forenkler identifiseringen av den fakturerbare parten for utgående direkte eller viderekoblede anrop. Hvis PSTN-leverandøren din bruker en annen faktureringshode, kan du kopiere informasjonen fra P-Charge-Info-hodet på den lokale gatewayen til det nødvendige faktureringshodet.

For steder som bruker Cloud Connect for eller Cisco-anropsabonnementet som PSTN-alternativ, velger du ganske enkelt det respektive PSTN-valget for stedet under oppsettet. Hvis lokasjonen bruker enten Cloud Connect for eller lokal PSTN, må du legge til telefonnumrene som ble bestilt i forrige trinn. Numre kan legges til som inaktive hvis du ikke vil at de skal inkluderes i samtalerutingen med en gang. Du kan aktivere disse numrene senere når de tilordnes brukere eller funksjoner.

Det er viktig å alltid angi hovednummeret for hvert sted. Hovednummeret kan tilordnes enten en bruker eller en funksjon, for eksempel en automatisk svarer. For å aktivere telefonsvarer på stedet, sørg for å angi pilotnummeret for telefonsvarer, også kjent som taleportalnummeret.

Ytterligere innstillinger for å ringe til steder inkluderer konfigurering av detaljer for nødanrop, for eksempel nødnummeret for tilbakeringing, varslingsalternativer og forbedrede funksjoner for nødanrop. Du bør også gjennomgå og justere opptaksinnstillinger, språkpreferanser og enhetskonfigurasjoner etter behov for hvert sted. Hvis organisasjonen din bruker forkortet internoppringing på nettet med signifikante numre i bedriften, husk å konfigurere en unik stedskode for stedet i de interne oppringingsinnstillingene. Til slutt, hvis ekstern oppringing krever et utgående siffer, må du sørge for å angi dette i innstillingene for ekstern oppringing. Når et utgående oppringingssiffer er konfigurert, anbefaler Cisco at man aktiverer håndheving av utgående oppringingssiffer for å sikre konsistens.

Integrasjon med lokal samtalekontroll

For å integrere med lokal samtalekontroll er det nødvendig å konfigurere trunker, rutegrupper, oppringingsplaner for bedrifter og både lokasjons- og globale innstillinger. Begynn med å sette opp trunkene og lokale gatewayene som er beregnet for sammenkobling med det lokale samtalekontrollsystemet. Dette trinnet er bare nødvendig hvis dedikerte trunker er nødvendige. Hvis eksisterende trunker og rutegrupper er tilstrekkelige for utrullingen din, kan de brukes på nytt for den lokale sammenkoblingen uten ytterligere konfigurasjon.

Når trunkene og rutegruppene er etablert, fortsett med å opprette bedriftens oppringingsplaner og tilordne riktig rutegruppe som destinasjon for hver oppringingsplan. Når integrering involverer flere lokale samtalekontrollsystemer koblet til via forskjellige trunker, vil det være nødvendig med flere oppringingsplaner. Det er viktig å sørge for at disse oppringingsplanene bare inneholder mønstrene som er nødvendige for å rute samtaler til lokale destinasjoner.

Hvis utrullingen din krever støtte for ruting av ukjente utvidelser, bør denne funksjonen aktiveres på lokasjonsnivå. I tillegg, når ruting av ukjent internnummer er aktivert, må du angi maksimal ukjent internnummerlengde i delen Samtaleruting mellom og lokaler i innstillingene for anropstjenester i . Dette sikrer sømløs samtaleruting og riktig håndtering av internnummerbaserte oppringingsscenarioer i ditt integrerte miljø.

Migrer brukere i grupper

Når du migrerer brukere fra til, kan det hende at du ikke kan flytte alle brukerne samtidig. Dette kan skyldes flere årsaker, inkludert, men ikke begrenset til, antall nettsteder eller brukere, hvor lang tid det tar å overføre et nettsted and/or gruppe brukere samtidig, begrensede IT- eller nettstedsressurser til å støtte endringsvinduet, varighet av endringsvinduet, endringens kompleksitet osv.

Når du migrerer brukere i faser, er det viktig å identifisere hvilke brukere som må migrere sammen i samme batch. Hovedmålet er å migrere brukere som er avhengige av hverandre for sine ringetjenester og -funksjoner, sammen. Du vil sørge for at alle ringefunksjonene deres (eksempel - samtalekøer) er fullt funksjonelle slik de var før overgangen.

Selv om du implementerer kallingssamarbeid mellom og med lokale gatewayer, kan du ikke dele delte tjenester eller funksjoner på tvers av denne forbindelsen. Derfor må du identifisere avhengighetene mellom brukere ved å se på funksjoner som:

Overvåking av andre brukere ved hjelp av BLF-er

I samme jaktpilot, anropskø osv.

Delte linjer

Bruk av samtalehenting

Bruker de samme parkeringsnumrene for samtaler

Intercom

Executive/Admin.

Et eksempel kan være en bruker som er en del av en jaktgruppe som blir overført til . Denne brukeren vil gå over til med jaktgruppen og med alle andre medlemmer av jaktgruppen. Derfor kan Hunt Group og medlemmene deres svare på anrop på den nye plattformen etter overgangen.

Dette blir mer utfordrende når brukere er koblet til forskjellige brukergrupper for forskjellige ringetjenester og -funksjoner. Dette vil kreve overføring av mer enn én brukergruppe og én anropstjeneste samtidig.

Bruk resultatet fra Migration Insights-verktøyet eller et tredjepartsverktøy du brukte i forberedelsesfasen for å bestemme hvilke brukere og funksjoner som skal grupperes sammen. Dette resultatet burde ha blitt brukt til å utvikle migreringsplanen din, og det vil gi deg innsikt i hvordan du grupperer brukere og funksjoner som må overføres sammen.

De viktigste trinnene når du overfører en gruppe brukere er:

Identifisere brukere som skal migreres sammen

Bekreft at alle brukere er inne

Bekreft at alle TN-er for brukerne finnes i

Bekreft riktig telefonnummerformat i katalogen

Sørg for at lisens- og innstillingsmalen for brukergruppene er riktig konfigurert.

Verifisere eller konfigurere alle anropstjenester og -funksjoner for brukergruppen (før eller under overgangen, etter behov)

Legg til brukere i gruppen med brukere som er aktivert for anrop i bedriftskatalogen

Utnytt verktøy – verktøy for migrering av brukere og funksjoner and/or tredjepartsverktøy

Disable/Delete user/device katalognummer og oppringing features/services på etter overgangen.

Etter at en gruppe brukere er migrert, test et delsett av brukerne for å bekrefte at alle anropsfunksjonene og -tjenestene deres fungerer som de skal. Hvis anropsfunksjoner som anropskø, søkegrupper osv. overføres med brukergruppen, må du teste at disse anropstjenestene fungerer som de skal.

Arbeidsområder

I refererer et arbeidsområde til et delt sted (som et konferanserom, et møterom eller en hot desk) som kan tilordnes enheter, utvidelser og brukere. I motsetning til tradisjonelle Unifed CM-telefoner er arbeidsområdene:

Stedssentrert: knyttet til fysiske rom.

Enhetsfleksibel: kan ha én eller flere enheter (bordtelefoner, tavler osv.).

Når arbeidsområder er identifisert som en del av overgangen til , kan de legges til under Enheter. Hvert arbeidsområde trenger en enhetstildeling, og hvis de allerede er i Unified CM, må de tilbakestilles eller klargjøres på nytt. Funksjoner som talepost, viderekobling og henting av anrop kan aktiveres eller deaktiveres, og policyer kan brukes for videosamtaler, samtaleparkering og mobilitet etter behov. Test hvert arbeidsområde ved å foreta interne og eksterne samtaler, og teste video-, konferanse- og mobilitetsfunksjoner. Til slutt, informer brukerne om eventuelle gjeldende prosesser for arbeidsplassenheter og bestillinger.

Hvis du vil ha mer informasjon om arbeidsområder i Arbeidsområder.

Klargjøringsenheter

Telefoner som for øyeblikket er registrert til, må migreres til som en del av skyovergangen. For å gjøre migreringen så enkel som mulig med minimal sjanse for feil, anbefaler Cisco å migrere fysiske steder eller avdelinger samtidig. Du kan imidlertid bli bedt om å migrere brukere i grupper på grunn av funksjonsavhengigheter. Se avsnittet Migrer brukere i grupper for mer informasjon.

Alle støttede telefoner du må gå over fra, må konfigureres som en bruker eller et arbeidsområde, og den fysiske telefonen må konfigureres på nytt for å registrere seg hos . I tillegg må fastvaren for telefonene i 7800- og 8800-serien oppgraderes fra Enterprise-fastvare til Multiplatform Phone (MPP)-fastvare. Denne prosessen inkluderer lasting av overgangsfastvare før lasting av MPP-fastvaren som kreves for registrering. Det krever også riktig migrasjonstillatelse. Cisco har forbedret denne prosessen de siste årene for å gjøre det enklere for deg å oppgradere Enterprise-telefonene dine til MPP-firmware. Hvis du vil ha mer informasjon om trinnene for å fullføre fastvareoppgraderingen, kan du se Konverter Cisco 7800- og 8800-seriens IP-telefoner mellom Enterprise- og MPP-fastvare.

I tillegg til trinnene som er beskrevet i denne artikkelen, finnes det et innebygd verktøy, Migrer telefonen din til Webex Calling, som du kan bruke til å migrere 7800- og 8800-telefonene dine fra Enterprise- til MPP-fastvare. Dette verktøyet lar deg også legge til telefonene og tilordne dem til de riktige brukerne eller arbeidsområdene. Hvis du vil ha mer informasjon om bruk av verktøy, kan du se Migrer telefonen din.

For telefoner i 9800-serien som er registrert med ovennevnte krav til fastvaremigrering gjelder ikke. Disse telefonene kjører PhoneOS, som støttes av både og . For å overføre disse telefonene til deg må du legge dem til i Webex Calling, tilordne dem til en bruker eller et arbeidsområde og deretter tilbakestille telefonene til fabrikkinnstillinger. PhoneOS-oppstartssekvens for registrering Figuren nedenfor viser PhoneOS-oppstartssekvensen og hvordan telefonen registreres når den er lagt til, selv om telefonen fortsatt er klargjort på and/or DHCP-alternativer (eksempel - 150) er i bruk.

PhoneOS oppstartssekvens for registrering

støtter fabrikktilbakestilling av PhoneOS-enheter for å tillate Zero-Touch-onboarding til. administratorer kan eksternt tilbakestille fabrikkinnstillingene for 9800- og 8875-telefonene via CUCM-administrasjonssidene, noe som eliminerer behovet for fysisk tilgang til telefonene for å logge inn på telefonene til. Denne funksjonen støttes med enhetspakkene fra 9. september 2025:

CUCM v15 – Unified Communications Manager versjon 15

CUCM v14 – Unified Communications Manager versjon 14.

Hvis du vil ha mer informasjon om registreringsprosessen for 9800-serien, kan du se Registreringsprosess.

I tillegg til Cisco IP-telefoner kan det være nødvendig med klargjøring av andre enheter som analoge telefonadaptere (ATA-er), trådløse telefoner (WiFi, DECT), videoenheter, talegatewayer og^{tredjepartsenheter og} -telefoner . Mange av disse enhetene har ikke en fastvareoppgraderingsbane som IP-telefoner for å overføre dem fra bedriftsfastvare til skyfastvare. Derfor skal du klargjøre hver av disse enhetene i Control Hub. Noen av disse kan ikke overføres til, og den tilsvarende modellen må erstatte den (f.eks. ATA 191/192) og andre vil kreve manuell omkonfigurering and/or programvareendringer.

Talegatewayer – Hvis du vil migrere den lokale gatewayen din, kan du se Migrere lokal gateway.
Hvis du vil ha mer informasjon om hvordan du konfigurerer talegatewayen VG400, VG410 eller VG420 i Control Hub, kan du se Lokal gateway

Analog telefonadapter (ATA) – For å komme i gang med Cisco ATA 191 og 192, se Cisco ATA.

Trådløs Wifi-telefon – For å integrere trådløs telefon 840 og 860, se Integrer trådløs Webex-telefon.

DECT trådløse telefoner – For å komme i gang med den nye Cisco IP DECT 6800-serien, se Cisco IP DECT.

For å bygge og administrere et digitalt DECT-nettverk i Control Hub, se Administrere DECT-nettverk

Hvis du vil ha mer informasjon om Cisco IP DECT 6800, kan du se Implementeringsveiledning

^{Tredjepartsenheter og -telefoner} – Samarbeid med tredjepartsleverandører^{på device/phone krav og prosessen for å migrere eller erstatte dem for å støtte .}

Konfigurer funksjoner

Eventuelle nødvendige anropsfunksjoner må klargjøres før eller under overgangen. Som omtalt i delen Migrer brukere i grupper, må anropsfunksjonene konfigureres og overføres når brukerne som bruker dem overføres.

Hvis du vil ha mer informasjon om hvordan du konfigurerer hver av funksjonene, kan du se de tilhørende hjelpeartiklene for konfigurasjon.

Automatiske svarere – For å administrere automatiske svarere, se Automatiske svarere

Samtaleparkering – For å administrere samtaleparkering, se Samtaleparkering

Samtalehenting – For å konfigurere samtalehentingsgruppen, se Samtalehenting

Samtalekøer – For å konfigurere samtalekøen, se Samtalekø

Jaktgrupper – For å administrere jaktgrupper, se Administrer jaktgruppe

Driftsmoduser – For å se anropsruting basert på driftsmoduser, se Anropsruting basert på driftsmoduser

Personsøkergrupper – For å konfigurere en personsøkergruppe, se Konfigurer en personsøkergruppe

Opptak – For å administrere samtaleopptak for , se Administrer opptak

Enkeltnummerkontakt – For å konfigurere enkeltnummerkontakt (hvor som helst på kontoret), se Konfigurer enkeltnummerkontakt

Talepostgruppe – Hvis du vil administrere en delt talepost og innkommende faksboks for , se Administrer talepost.

Aksepttesting

Aksepttesting sikrer at det migrerte miljøet oppfyller de funksjonelle kravene, fungerer som forventet og gir en sømløs brukeropplevelse på tvers av alle kommunikasjonsarbeidsflyter. Denne valideringsprosessen er mangesidig og dekker alt fra brukerklargjøring og nummertildelinger til driftsytelsen til avanserte ringefunksjoner.

Denne delen gir eksempler og fremhever viktige aspekter å vurdere under aksepttesting; den er imidlertid ikke ment å tjene som en uttømmende eller omfattende sjekkliste.

Brukerklargjøring og nummertildeling

Et grunnleggende aspekt ved aksepttesting innebærer å verifisere at alle brukere er klargjort nøyaktig og fullstendig i . Dette krever en grundig sammenligning mellom kildekatalogen () og den nylig etablerte brukerbasen for å sikre at alle brukerkontoer, sammen med tilhørende attributter som internnumre og direkte innringing (DID)-tildelinger, har blitt riktig migrert. Fullstendig klargjøring er avgjørende ikke bare for drift fra dag én, men også for løpende administrasjon og støtte.

Validering av nummertildeling inkluderer å bekrefte at hver bruker er tildelt riktig internnummer og eksternt nummer, og at disse numrene rutes riktig i både interne (på nettet) og eksterne (PSTN) samtaleflyter. Det er viktig å sjekke for eventuelle overlappinger, manglende tildelinger eller feilkonfigurasjoner som kan føre til feil i samtalerutingen eller avbrudd i tjenesten.

PSTN-anropsflyt og presentasjon av nummerpresentasjon

En robust prosedyre for aksepttesting må omfatte ende-til-ende-validering av PSTN-anropsflyter. Dette inkluderer både innkommende og utgående anropsscenarioer. For innkommende PSTN-anrop bør testteamet bekrefte at anropene leveres til de tiltenkte endepunktene, enten det er individuelle brukere, anropskøer, søkegrupper eller automatiske svarere. Utgående PSTN-anrop må foretas på riktig måte, med særlig vekt på korrekt levering og presentasjon av informasjon om innringer-ID. Dette innebærer å sørge for at riktig navn og nummer på den som ringer vises til eksterne mottakere, i samsvar med organisasjonens retningslinjer og regulatoriske krav.

Testing bør også ta for seg failover-scenarioer, som håndtering av utilgjengelige endepunkter eller nettverksforstyrrelser. Dette bidrar til å bekrefte at reservemekanismer og alternativ ruting fungerer som de skal, og opprettholder tjenestekontinuitet og pålitelighet.

Samtaleflyter på nettet

Interne, eller nettverksbaserte, samtaleflyter danner ryggraden i bedriftskommunikasjon. Aksepttesting på dette området bekrefter at samtaler mellom brukere i organisasjonen rutes riktig, med funksjoner som overføring, venting, viderekobling og konferanser som fungerer som tiltenkt. Integriteten til oppringingsplaner, tilkobling mellom internlinjer og støtte for organisasjonens anropsregler må bekreftes.

Håndtering av brukeranrop og funksjonsvalidering

Et viktig aspekt ved aksepttesting innebærer å validere hvordan brukere håndterer samtaler ved hjelp av og støttede bordtelefoner. Denne prosessen fokuserer på å bekrefte at de daglige arbeidsflytene for samtaler er intuitive og pålitelige, og at brukerne har sømløs tilgang til kjernefunksjonene som er nødvendige for rollene deres. Testingen bør vurdere hvor enkelt brukere kan ringe og motta samtaler, administrere vent- og gjenopptaksfunksjoner, og utføre både blinde og konsultative overføringer. Det er også viktig å bekrefte at viderekobling, konferanser og andre avanserte funksjoner, som parkering og henting av samtaler eller aktivering av «ikke forstyrr», er lett tilgjengelige og fungerer problemfritt.

Opplevelsen bør evalueres med tanke på klarhet og respons, med tanke på hvordan brukerne samhandler med samtalehistorikk, talepost og integrerte kataloger. Det bør legges ekstra vekt på muligheten til å flytte aktive samtaler mellom enheter og bruke kontroller under samtaler effektivt i applikasjonen eller på fysiske telefoner. Det endelige målet er å sikre at sluttbrukeropplevelsen er konsistent, effektiv og fullt ut støtter organisasjonens kommunikasjonsbehov etter migreringen.

Samtalekøer: Erfaring med agent og veileder

Anropskøer brukes ofte til å håndtere innkommende anrop med høyt volum. Aksepttesting fokuserer her på flere dimensjoner. Først bør det bekreftes at anrop distribueres til agenter i henhold til den konfigurerte kølogikken, for eksempel Round Robin, lengste inaktiv tid eller samtidig ringing. Presentasjonen av køanrop på agentens skrivebord må undersøkes for klarhet og brukervennlighet, slik at agentene effektivt kan motta, sette på vent og overføre anrop.

For veiledere bør skrivebordsopplevelsen evalueres for funksjoner som sanntidsovervåking, innbrudd i samtaler og analyser eller innsikt i køytelse. Dette inkluderer, men er ikke begrenset til, validering av dashbord og rapporteringsverktøy som gir handlingsrettede data om samtalefordeling, agentaktivitet og kømålinger.

Jaktgrupper: Samtalefordeling

Søkegrupper er en nøkkelmekanisme for å distribuere anrop til forhåndsdefinerte sett med brukere. Aksepttesting må bekrefte at anrop rutes til gruppemedlemmer basert på den konfigurerte søkealgoritmen, og at overløp, videresending og manglende svar håndteres i henhold til designet. Det er avgjørende for driftsmessig konsistens og brukertilfredshet å sørge for at gruppemedlemskap og samtaleruting samsvarer med de som tidligere er etablert i .

Automatiske svarere: Kunngjøringer og menyoperasjoner

Automatiske svarere representerer frontlinjen innen automatisert samtalehåndtering. Testingen må dekke avspilling av kunngjøringer, nøyaktigheten av innspilte hilsener og riktig funksjon av menystrukturer. Menyvalg bør på en pålitelig måte dirigere innringere til riktig avdeling, person eller eksterne numre. Testing bør også inkludere ugyldige eller tidsavbruddsscenarier for å bekrefte at innringere får tydelig veiledning eller blir omdirigert som tiltenkt.

Mobilsvar-operasjon

Til slutt er talepostfunksjonaliteten avgjørende for brukeropplevelsen. Aksepttester bør bekrefte at talepostkasser er riktig tilordnet og tilgjengelige, både internt i organisasjonen og eksternt. Muligheten til å ta opp, hente og administrere meldinger må bekreftes, sammen med levering av varsler.

Optimaliser

PSTN-migrering til Cloud Connect for

Optimaliser lokal infrastruktur

Bruk analyser og feilsøking

PSTN-migrering til Cloud Connect for

Når alle endepunkter og brukere er migrert til skyanrop, er det eneste formålet med Unified CM å fungere som en transitt mellom PSTN-gatewayene og via den lokale gatewayen. Å fjerne PSTN-gatewayer og lokal gateway fra bildet ved å bruke Cloud Connect som PSTN-tilgang for alle Webex Calling-brukere har flere fordeler, inkludert kostnadsreduksjon og forbedret pålitelighet. For å overføre lokal PSTN-tilgang til Cloud Connect for , følg disse trinnene:

Cloud Connect for partnervalg.

Se listen over Cloud Connect-partnere og velg blant de tilgjengelige partnerne som er tilgjengelige for organisasjonens lokasjon.

Cloud Connect for validering.

Før du bytter PSTN-tilgang for steder til Cloud Connect, bør tilkoblingen til PSTN via den valgte Cloud Connect-partneren bekreftes og valideres. For dette formålet må en testlokasjon klargjøres med noen testbrukere klargjort på testlokasjonen. PSTN-tilgang for denne testlokasjonen settes deretter til Cloud Connect-partneren før PSTN-tilkoblingen validerer ved hjelp av testtelefonene. Etter vellykket validering kan testlokasjonen avregistreres.

Nummerportering.

For å forberede overføringen til Cloud Connect, må det legges inn en portordre for alle numre som for øyeblikket er tilordnet PSTN-trunken som avsluttes den. Alle numre må porteres til Cloud Connect-partneren. For å opprettholde tilgjengelighet mellom lokasjoner, må alle numre fra alle lokasjoner porteres samtidig.

Bytt til Cloud Connect-partner.

På datoen for overgangen må PSTN-tilgang for alle steder settes til den skytilkoblede PSTN-leverandøren, og innkommende og utgående tilkobling må bekreftes.

Som omtalt i PSTN-delen av designkapittelet, kan kunder også velge å flytte PSTN-tilgangen sin til Cloud Connect i starten av overgangen ved å bruke PSTN-trunking for hybriddistribusjoner. Hvis du vil ha mer informasjon, kan du se PSTN-trunking for hybrid Webex Calling-distribusjoner. I så fall skjer PSTN-tilgang via lokal gateway under overgangen, og etter at alle brukere er flyttet, er det ikke noe ekstra PSTN-relatert migreringstrinn annet enn avvikling og lokale gatewayer.

Optimaliser lokal infrastruktur

Når alle brukere er overført til og alle endepunkter er overført til skyregistrering (eller er avviklet), må du oppdatere riktig lokal infrastruktur nå som skyanrop er i bruk. Oppdateringer av infrastrukturen inkluderer:

Fjern lokale DNS SRV-oppføringer for samtalekontroll og meldinger fra den/de lokale DNS-serveren(e), inkludert cisco_uds._tcp.<domain>, cup_login._tcp.<domain>. Disse SRV-postene er ikke lenger nødvendige for klienttjenesteoppdagelse.

Fjern kantrelaterte DNS SRV-oppføringer fra det offentlige DNS-systemet, inkludert collab_edge._tls. [].<domain>. Disse SRV-postene er ikke lenger nødvendige for klienttjenesteoppdagelse av samarbeidstjenester på kanten.

Oppdater alle relevante DHCP-områder for å fjerne alternativ 66 og alternativ 150 TFTP/boot serveradresser. Disse omfangene er ikke lenger nødvendige for oppdaging og nedlasting av konfigurasjon for endepunktskallkontroll.

Update/remove passende oppringingspeer i Lokalt Gateway/CUBE den ruten kaller til og fra Unified CM. Disse oppringingsmotpartene er ikke lenger nødvendige for lokal samtaleruting.

Slett eller fjern alle virtuelle maskiner og klyngenoder and/or servere. Gjenbruk dataressurser og maskinvare etter behov. Disse ressursene er ikke lenger nødvendige for samtalekontroll og edge-tjenester.

Slett eller fjern alle virtuelle maskiner i klyngenoden and/or servere. Gjenbruk dataressurser og maskinvare etter behov. Disse ressursene er ikke lenger nødvendige for talepost og Unified Messaging-tjenester.

Opprydding: Etter migrering av PSTN-tilgang til skytilkoblet PSTN, kan PSTN-trunker, PSTN-gatewayer og lokal gateway avvikles.

For enhver eksisterende lokal E911-løsning, slett alle lokasjoner eller numre som har blitt migrert til, og når den fullstendige overføringen er fullført, fjern virtuelle maskiner eller servere for applikasjonen. Gjenbruk dataressurser og maskinvare etter behov. Disse ressursene er ikke lenger nødvendige for nødanrop og posisjoneringstjenester.

Navneidentifikasjonsnumre (DN-er) som tilhører migrerte brukere bør plasseres i en skjult partisjon for å unngå feil i anropsrutingen og for å sikre at alle CSS-er har prioritert tilgang til skybanen til de samme DN-ene.

Oppdater den fysiske utsendbare plasseringen og nettverkselementet i Horizon Mobility når det skjer endringer. Vanlige aktiviteter som krever oppdateringer er:

Utskifting av nettverkssvitsj

Utskifting av trådløst tilgangspunkt

Endringer i DHCP-omfang

Fysiske endringer inne i bygningen (hvis det er lurt å cubical/office)

Fysisk utvidelse eller innsnevring av kontorplass inne i en bygning.

Bruk analyser og feilsøking

tilbyr omfattende analyse- og feilsøkingsfunksjoner som hjelper deg med å visualisere og spore utrullingen din. Disse dekker mediekvalitet, detaljert samtalehistorikk, samtalekø, søkegruppe og analyse av automatiske svarere. Et eksempel på mediekvalitetsanalyse er vist i figur mediekvalitetsanalyse.

analyse av mediekvalitet

Under feilsøking kan hvert anrop som gjøres med vises med detaljert informasjon om viktige problemer knyttet til mediekvalitet og signalisering for å finne frem til medieproblemer samt mislykkede anrop, som vist i figur feilsøking av mediekvalitet.

Feilsøking av mediekvalitet

Feilsøking kan også integreres med andre Cisco-produkter som ThousandEyes og Meraki-svitsjer for å gi en enda rikere integrert opplevelse i Control Hub. Hvis du vil ha mer informasjon om bruk av Webex Calling -analyse og feilsøking, kan du se Feilsøke Webex Calling-anrop i Control Hub.

1	Opprett en dedikert synkroniseringsgruppe: I bedriftskatalogen (Microsoft Entra ID eller AD) oppretter du en sikkerhetsgruppe spesielt for synkronisering (for eksempel synkroniseringsgruppe).
2	Fyll gruppen med målbrukere: Legg bare til brukerne du vil synkronisere (for eksempel en testgruppe under pilotfasen) i denne gruppen. Dette lar deg kontrollere hvem som er inkludert i synkroniseringsprosessen tett.
3	Konfigurer synkroniseringsavtalen med gruppebasert filtrering: Når du konfigurerer synkroniseringsavtalen i Directory Connector eller Entra ID-klargjøring, konfigurerer du omfanget slik at det bare inkluderer brukere som er medlemmer av den angitte gruppen. For Microsoft Entra ID kan du bruke gruppebaserte tildelinger i klargjøringsinnstillingene For AD kan du definere et LDAP-filter som bare inkluderer brukere som tilhører den angitte gruppen.
4	Utvid gruppen etter behov: Når du går videre til bredere distribusjonsfaser, legger du bare til flere brukere eller grupper i synkroniseringsgruppen. Synkroniseringsomfanget utvides automatisk til å omfatte disse brukerne, noe som muliggjør kontrollert og gradvis utrulling. Eksempel på implementeringstrinn: I aktiv katalog: Opprett en sikkerhetsgruppe med navnet synkroniseringsgruppe. Legg til ønskede pilotbrukere i denne gruppen. Sett opp Directory Connector med et LDAP-filter som: (MemberOF=CN=WebEx Sync Group, OU = Groups, DC=Ditt domene, DC=COM). I Microsoft skriver du inn ID: Opprette en gruppe med navnet synkroniseringsgruppe Tilordne gruppen til klargjøringsinnstillingene i Entra ID Bare brukere i denne gruppen vil bli klargjort til. Test alltid gruppebasert synkronisering i et ikke-produksjonsmiljø før du søker på hele organisasjonen Gjennomgå gruppemedlemskap regelmessig for å sikre at bare autoriserte brukere synkroniseres For løpende administrasjon kan du automatisere oppdateringer av gruppemedlemskap basert på forretnings regler eller HR-systemer hvis mulig. Referanser: Synkroniser Entra ID-brukere til Control Hub Konfigurere veiviserappen Entra ID i Control Hub Katalogkontakt

Cisco AI Assistant

Takk for tilbakemeldingen.

Implementeringsveiledning for migrering

Før du begynner

Oversikt

Kjernekomponenter

PPDIO prosessoversikt

Generell beskrivelse av PPDIO

Bruke PPDIO for Unified CM til Webex Calling migreringsprosjekter

Forberede

Planlegg

Utforming

Implementere

Optimaliser

PPDIO tilbakemeldingssløyfer

Migrasjonstilnærming

Forberede

Forretnings- og tekniske krav

Hvorfor det er viktig å samle krav:

Forretningskrav

Tekniske krav

Nettverksberedskap og krav

Konfigurere skytilkoblet UC

Vurdering av dagens miljø

Lisensiering

Steder/steder

Inventar eksisterende enheter/klienter

Bekreft enhetens kvalifisering

Brukere

PSTN-tilkobling

Funksjoner og funksjonsbruk

Cisco-integrasjoner: Unity Connection UCCX UCCE

Samtaleopptak

Tredjepartsintegrasjoner

Planlegg

Prosjektplan på høyt nivå

Migrasjonsreise - ett eller to trinn?

Alternativ 1: Enkelt trinnvis brukermigrering

Alternativ 2: Dobbeltrinns brukermigrering

Trinn 1

Trinn 2

Utforming

Regionvalg

Steder

PSTN

Oppringingsplan

Lokal nummerplan i

oppringingsplan

Opptak

1. Valg av leverandør av samtaleopptak

2. Regionvalg

Nødanrop

Lisensiering

Manuell tildeling gjennom

Automatiske lisenstildelingsmaler

Massetildeling gjennom CSV-mal

API-basert oppgave

Lisenskrav

Brukerklargjøring

Brukergrupper

Anbefalt tilnærming når du migrerer fra til

Utforming av brukergrupper

Enkel pålogging (SSO)

Støtte for flere IdP

1. Fusjoner og oppkjøp

2. Flere uavhengige IT-avdelinger

3. Ulike brukergrupper eller domener

4. Støtte for ulike autentiseringsprotokoller

5. Forbedret sikkerhet og samsvar

6. Forenklet brukeropplevelse

Duo MFA med SSO for

Funksjoner

Automatisk ledsager

Ring Park

Henting av anrop

Anropskø

Jaktgruppe

Driftsmoduser

Personsøkingsgruppe

Innspillinger