- Start
- /
- Artikel
Implementeringsguide för migrering
Den strukturerade migreringsprocessen från lokal Cisco Unified CM till molnbaserad Webex Calling, med hjälp av PPDIO-metoden. Detta innebär kritiska konstruktionsöverväganden såsom regionval, uppringningsplaner, räddningstjänster och samtalsinspelning. Processen också specificerar licensiering, användarprovisionering, SSO och nätverksberedskap för att säkerställa en smidig och Effektiv övergång.
Innan du börjar
Den här guiden är avsedd för team eller individer med erfarenhet av att konfigurera och administrera Cisco Unified Communications Manager (Unified CM) och Cisco-slutpunkter, inklusive IP-skrivbordstelefoner, videoenheter och Jabbers mjukklienter. I hela detta dokument finns länkar till produkt- och supportdokumentation för att hjälpa till.
Detta dokument fokuserar endast på övergångar från Unified CM till Webex Calling flera hyresgäster. Termen Webex Callingi detta dokument hänvisar alltid till Webex Calling flera hyresgäster.
Innan migreringen från Unified CM till på Webex Calling börjas är det absolut nödvändigt att ha en omfattande förståelse för Webex Calling lösningen och dess respektive komponenter. En lyckad migrering kräver kunskap om Webex Calling arkitek turen, servicemodellerna, distributionsalternativen och tillhörande funktioner för att korrekt kartlägga befintliga Unified CM arbetsbelastningar och utforma en effektiv övergångsplan.
En grundlig förståelse av följande Webex Calling komponenter är avgörande för att informera om en effektiv övergångsstrategi och operativ beredskap.
-
Kontrollnav
-
Tillhandahållande av katalog och användare
-
Webex Callingplattform
-
Slutpunkter för samtal som stöds
-
PSTN-anslutningsalternativ
-
Webex Callinguppringningsplan och nummerhantering
-
Säkerhets- och efterlevnadsfunktioner.
Mer information finns i Cisco Preferred Architecture forWebex Calling.
Den här guiden belyser verktyg och processer som ska användas under hela övergångscykeln. Men en övergång från lokalt samtal,Unified CM, till en ny molnsamtalsplattform,Webex Calling, kan vara en betydande ansträngning med potentiella affärsmässiga, tekniska och komplexa utmaningar. För att hjälpa dig att övervinna dessa utmaningar har Cisco några olika alternativ tillgängliga för att hjälpa dig med din resa. Det är viktigt att granska informationen på Enterprise cloud call - Samtalsmigrering och förstå varje alternativ och hur vart och ett av dem eventuellt kan hjälpa dig med din egen migrering.
-
Webex-migreringsverktyg: självbet jäning, kostnadsfria verktyg inbyggda i Control Hub för att effektivisera din övergång till Webex Calling
-
Certifierade migreringsleverantörer: Cisco-validerade mjukvaru- och verktygsleverantörer som har utvecklat migreringslösningar för att hjälpa Webex-partners och kunder med komplexa och stora migreringar. Dessa lösningar kan hjälpa till att förenkla, hantera och påskynda övergången till Webex Calling
-
Webex Setup Assist: en Cisco-ledd migreringstjänst som guidar kunder och partners genom distributionen Webex Calling och konfigurationen, som behövs för att framgångsrikt migrera Unified CM användare och tjänster till. Webex Calling
Översikt
Med tillväxten av molnlevererade samarbetstjänster vill fler kunder flytta sina befintliga samarbetsarbetsbelastningar till molnet med tanke på löften om minskad total ägandekostnad, förenklad hantering, kontinuerlig leverans av funktioner, ökad skala och överlägsen tillförlitlighet som ingår i molnbaserade tjänster. När kunderna vill göra övergången från lokala samarbetstjänster till molntjänster är det viktigt för dem att förstå vad övergången innebär och vilka steg som krävs för att genomföra övergången.
Syftet med detta dokument är att ge vägledning för distribution för kunder som specifikt vill övergå från lokalt Unified CM till Webex Calling i molnet. Den här distributionsguiden förutsätter att läsaren har en grundläggande förståelse för samtalsövergången mellan Unified CM ochWebex Calling, inklusive vilka förändringar när den här övergången görs och vad skillnaderna är när samtalsbelastningen flyttas från lokalt till molnet. Innan du fortsätter, se till att du har granskat och känner till informationen på övergångskartan. Detta övergångskartdokument ger information om förändringarna och skillnaderna i denna övergång.
Som visas i figur Lokal samarbetsarkitektur: samtalskontroll och fjärråt komst innehåller en typisk lokal distribution olika samarbetsinfrastruktur komponenter i nätverket, en samtalskontrollplattform, en kantplattform, hårdvaru- och mjukvaru slutpunkter och i vissa fall även konferens- och schemaläggningsplattformar. I Cisco- arkitekturen skulle detta inkludera Unified CM samtalskontroll, Expressway för fjärråtkomst och business-to-business (B2B) edge-tjänster, Cisco Meeting Server/ Cisco Meeting Management för lokala konferenser, Unity Connection för röstmeddelanden och användarvänd maskinvara (Cisco IP-telefoner, Cisco Desk och Room video system) och programvara () IP-baserade slutpunkter. Cisco Jabber Dessa komponenter kan variera något i vissa miljöer, men detta är utgångspunkten för övergången som beskrivs i resten av detta dokument.
Arkitekturen som visas i figur Lokal samarbetsarkitektur: samtalskontroll och fjärråtkomst baseras på Preferred Architecture (PA) för Cisco Collaboration Enterprise On-Premises Deployments. Mer information om Enterprise On-premise finns i Ciscos föredragna samarbetsarkitekturer.
Före: Tabellen med lokala anropsinfrastrukturkomponenter visar nyckelelementen Webex Calling i den lokala arkitekturen innan övergången till molnet.
| Produkt | Beskrivning |
|---|---|
| Unified CM | Lokal samtalskontroll som tillhandahåller enhetsregistrering och samtalsdirigeringstjänster |
| Cisco Expressway-C/E | Edge-infrastruktur som tillhandahåller mobil- och Remote Access (MRA) och företag-till-företag (B2B) funktionalitet som gör det möjligt för fjärranslutna slutpunkter att ansluta säkert utanför organisationen . Expressway distribueras parvis för att tillhandahålla brandväggstra vering för externa slutpunkter. |
| Ciscos mötesserver (CMS), Ciscos möteshantering (CMM) och Cisco TelePresence Management Suite (TMS) | Lokal infrastruktur för röst-, video- och webbkonferenser som tillhandahåller flerpunktsmöten, möteshantering och schemaläggningsfunktioner. [Valfritt] |
| Cisco Unity Connection | Lokal röstmeddelandeplattform som tillhandahåller röstbrevlåda och enhetliga meddelandefunktioner. [Valfritt] |
| Cisco Desk, Cisco Room, Cisco Board, Cisco IP-telefoner och Cisco Jabber | IP-baserade enheter som är registrerade på Unified CM och som tillhandahåller röst- och videosamtalsfunktioner |
Som illustreras i Figur Övergångsbeslut: lokalt samtal till Webex Calling, kunder som har en lokal samtalskontroll med Unified CM och skrivbords- och video-IP-slutpunkter kan välja att övergå arkitekturen till en molnarkitektur. Webex Calling
Beslutet måste fattas utifrån kundens funktionskrav. Kunder som har följande krav bör överväga noga innan de fattar detta beslut och kan i slutändan besluta att behålla samtalskontrollen lokalt:
- Telefonmodeller stöds inte av Webex Calling
- Komplexa eller många integrationer med andra lokala system eller lösningar, särskilt där Webex Calling det är svårt att replikera dessa integrationer med eller inga motsvarande alternativa lösningar finns tillgängliga
- Komplex uppringningsplan, mycket detaljerade serviceklasser eller båda
- Begränsad, begränsad eller opålitlig internetåtkomst
- Stränga datasekretess- och ägarpolicyer
- Efterlevnadskrav för inspelning och lagring av media lokalt eller i landet
- Tredjepartsintegrationer utan genomförbar alternativ integration Webex Calling
- Kontaktcenterintegrationer där kontaktcenterintern inte flyttar till molnet ännu.
Det här dokumentet fokuserar på kunder med Unified CM samtalskontrolldistributioner som vill förstå de allmänna stegen, övervägandena och kraven för att möjliggöra Webex Calling distribution som beskrivs i nästa avsnitt.
Kärnkomponenter
Målarkitekturen för denna migrering innehåller flera nya komponenter. Detta inkluderar Webex Calling tjänsten för molnbaserade samtal, Webex App, Cisco Directory Connector för identitetsintegrering och Local Gateway (LGW) för PSTN- åtkomst, samt lokal till molnsamtalsintegrering. Ciscos samtalsplaner eller Cloud Connected PSTN (CCP) som underlättas av en Cloud Connect för Webex Calling partner är ytterligare alternativ för PSTN-åtkomst.
Som visas i Figur A fter: Webex Calling Architecture läggs de nya komponenterna (Webex Calling, Kataloganslutning, Lokal gateway och Survivalability-gateway) till i den befintliga lokala distribu tionen.
Efter: Tabellen för molnsamtalsinfrastrukturkomponenter visar de nya elementen i arkitekturen efter övergången till Webex.
| Produkt | Beskrivning |
|---|---|
| Webex Calling | Molnbaserad samtalstjänst som levereras från Webex-plattformen och tillhandahåller slutpunktsregistrering och samtalsdirigering |
| Cisco-kataloganslutning | Windows-program som körs på en Windows-domändator som tillhandahåller identitet
ssynkronisering mellan det lokala företaget Active Directory och identitetslagret
för Webex-organisationen. För kunder som flyttar från lokalt Active Directory till Entra ID använder identitetsintegrationen med Webex istället för Cisco Directory Connector appen Entra ID Wizard. |
| Lokal gateway | En lokal gateway fungerar som en bro mellan kundens lokala enhetliga kommunikationsnätverk och Webex Calling molnet. Det kan distribueras lokalt eller hostas av en partner, vilket ger PSTN- åtkomst för molnregistrerade slutpunkter samt samtalsintegration mellan registrerade och moln Unified CM registrerade slutpunkter. Cisco IOS-XE Integrated Services Router (ISR 1100- och 4000-serien), Cisco Catalyst 8200/8300-serien, Cisco Catalyst 8000V Edge- programvara och olika certifierade tredjeparts Session Border Controllers (SBC) kan användas som LGW för en stegvis migreringsmetod. |
| Gateway för överlevnadsförmåga | Survivalability Gateway (SGW) är en lokal IOS-XE-baserad gateway som tillhandahåller reservsamtalstjänster till slutpunkter på plats Webex Calling under nätverksavbrott. |
| Ciscos samtalsplan, Cloud Connect för Webex Calling | Cisco Calling Plan och Cloud Connect for Webex Calling är molnbaserade alternativ för PSTN-åtkomst för Webex Calling slutpunkter. PSTN-åtkomst underlättas av en PSTN-leverantör i molnet och kräver ingen lokal utrustning. |
| Webex-appen | Klientapplikation som körs på stationära OS (Windows, Mac) eller mobilt operativsystem (Android, iOS) och registreras direkt på Webex Calling plattformen för samtalsfunktionalitet. |
PPDIO processöversikt
PPDIO- processen står för Prepare, Plan, Design, Implementation och Optimize. Det är en strukturerad Cisco-metod som guidar projekt från första bedömning till kontinuerlig förbättring, vilket säkerställer effektiva och framgångsrika distributioner eller migreringar.
Allmän beskrivning av PPDIO
-
Förbered: Utvärdera den nuvarande miljön, samla in krav och anpassa intressenter för att skapa en solid grund.
-
Planera: Utveckla detaljerade projektplaner inklusive tidslinjer, resurser och riskreducerande strategier.
-
Design: Arkitektera mållösningen skräddarsydd för affärsmässiga och tekniska behov.
-
Implementera: Utför distributionen eller migreringen enligt designen, validera funktionalitet och prestanda.
-
Optimera: Förbättra lösningen kontinuerligt efter implementeringen genom att övervaka prestanda, förfina konfigurationer och utnyttja automatiserings- och integrationsverktyg.
Använda PPDIO för Unified CM att Webex Calling migrera projekt
Vid övergången från Unified CM till Webex Calling ger PPDIO-processen en tydlig färdplan för att säkerställa en smidig och effektiv övergång:
Förbered
-
Bedöma befintlig Unified CM miljö och migrationsberedskap
-
Samla in detaljerad data om användare, enheter, nätverk och beroenden
-
Samla in platsinformation inklusive nödsvarsadress, antal användare, internet åtkomst, PSTN-åtkomst
-
Identifiera risker och definiera projektets omfattning för att anpassa alla intressenter.
Planera
-
Skapa en omfattande migreringsplan med batchscheman, resurstilldelningar och tidslinjer
-
Definiera uppgifter som uppgraderingar av enhetens firmware, licenstilldelning och användarintroduktion
-
Koordinera migreringsfönster med Cisco och partners för att minimera störningar.
Utformning
-
Mappa aktuella Unified CM konfigurationer, uppringningsplaner och användarprofiler till Webex Calling motsvarigheter
-
Utforma Webex Calling miljön, inklusive PSTN-strategi (tillfällig och slutlig), platser, användarroller och integrationspunkter som lokal gateway (CUBE) och katalogsynkronisering
-
Planera för samexistensscenarier där Unified CM och Webex Calling fungerar samtidigt under migrering.
Implementera
-
Använd Control Hub-migreringsverktyg tillsammans med verktyg från tredje part för att utföra ändringar av enhetens firmware-läge, funktionskonfiguration och användarmigreringar
-
Använd massoperationer och provisionering med Webex API:er för att effektivisera storskaliga migreringar och konfigurationer
-
Utför licenstilldelning, enhetsregistrering och konfigurationsuppdateringar
-
Validera migreringsframgång genom testning och operativ verifiering.
Optimera
-
Kontinuer Webex Calling ligt övervaka prestanda och användarupplevelse
-
Förfina konfigurationer och arbetsflöden baserat på operativa data och feedback
-
Utnyttja automatiserings- och integrationsfunktioner för att förbättra effektiviteten och skalbarheten
-
Avveckla äldre Unified CM komponenter efter behov och ge kontinuerligt stöd för dag 2-operationer.
Detta förbättrade PPDIO-tillvägagångssätt säkerställer en kontrollerad, transparent och effektiv migrering från Unified CM tillWebex Calling, med hjälp av Ciscos verktyg, API:er och partnerekosystem för att upprätthålla affärskontinuitet och förbättra samarbetsförmågan.
PPDIO återkopplingsslingor
Högnivåöversikten som visas i figur iterationer medan PPDIO körs illustrerar en enda återkopplingsslinga från optim eringsfasen tillbaka till förberedelsefasen. Detta innebär att det, efter den första implementeringen, finns en kontinuerlig möjlighet till kontinuerlig förbättring. Varje optimeringscykel kan identifiera nya krav eller områden för förbättring, som kan hanteras genom efterföljande projekt eller initiativ. Dessa enskilda projekt följer i sin tur var och en den etablerade livscykeln PPDIO (Prepare, Plan, Design, Implement, Optimize). Detta iterativa tillvägagångssätt säkerställer att systemet förblir anpassat till utvecklande affärsmål och tekniska framsteg, vilket främjar en kultur av kontinuerlig förfining och anpassningsförmåga.
Under genomförandet av PPDIO-processen är det vanligt att resultat i de senare faserna kräver omprövning och eventuellt revidering av beslut som fattats i tidigare steg. Exem pelvis kan problem som uppstått under genomförandefasen, såsom identifiering av ok larheter i konstruktionen eller saknade detaljer, avslöja att vissa aspekter inte behandlades fullt ut under utformningsfasen. I sådana fall blir det nödvändigt att upprepa tillbaka till relevant tidigare fas för att lösa dessa problem innan du fortsätter. Denna iterativa återkopplingsm ekanism, som illustreras i figur Unified CMassisterad PPDIO-process säkerställer att lösningen valideras och förfinas noggrant, vilket i slutändan bidrar till en mer robust och effektiv distribution.
När man genomför en övergång från Unified CM till Webex Calling kan varje fas i PPDIO-processen dra stor nytta av information som samlats in från den befintliga Unified CM miljön. Till exempel kan omfattande inventeringar av användare, telefonnummer, samtals funktioner och uppringningsplanskomponenter extraheras från den aktuella Unified CM konfigurationen. Dessa data kompletterar information som tillhandahålls direkt av intressenter och hjälper till att effektivisera planerings- och designaktiviteter. Att utnyttja lämpliga verktyg för att automatisera dat autvinning och analys förbättrar inte bara noggrannheten utan påskyndar också den övergripande processen. Genom att utnyttja insikter från den befintliga distributionen Webex Calling kan övergången till utföras mer effektivt än en traditionell greenfield-implementering, samtidigt som den strukturerade PPDIO-metoden följs. Denna process illustreras i figur Unified CMassisterad PPDIO-process.
Migrationsstrategi
När du planerar din övergång från lokalt Unified CM tillWebex Calling, måste du bestämma hur du ska närma dig den här resan. Först måste du bestämma om migr eringen kommer att vara en flash-cut (allt på en gång) eller en stegvis strategi (migrera grupper av användare/enheter över en längre period).
Att göra en flash-cut- migrering flyttar alla dina användare och enheter snabbast. Med den här metoden flyttar du alla användare och enheter från lokalt Unified CM till Webex Calling samtidigt. I huvudsak är det ett enda migreringsfönster för alla användare och enheter. När migreringen är klar kommer alla dina användare och enheter att vara på Webex Calling plattformen och all din Unified CM infrastruktur kan avvecklas. Många organisationer kan dock inte använda det här tillvägagångssättet på grund av omfattningen och storleken på deras samtalsdistribution.
Det andra tillvägagångssättet är en ste gvis migration. De flesta organisationer kommer att använda detta tillvägagångssätt eftersom det ger bättre kontroll, hantering och skalning med migreringen. Det är också bättre lämpat för större UC-driftsättningar och/eller distributioner över flera regioner. Därför fokuserar detta dokument på det steg visa tillvägagångs sättet med två steg i övergången.
Som visas i figuren nedan Fas ad samtalsövergång: Hybrid och moln resulterar den första övergångsfasen (fas 1) i en samexistensdistribution med dubbla samtal smiljöer. I den här fasen övergår vissa användare, enheter och mjuka klienter till Webex Calling medan andra fortfarande är på den lokala samtalskontrollenUnified CM. Den sista övergångsfasen (fas 2) resulterar i en ren moln samtalsmiljö där alla användare, enheter och mjuka klienter har övergått helt till Webex Calling plattformen.
Hur lång tid det tar för en organisation att helt övergå till molnsamtal varierar beroende på dess nuvarande distribution. I vissa fall kan en organisation göra den första övergången och förbli i samexistens dubbla samtalskontrollfas (fas 1) under en längre period (månader eller till och med år), medan i andra fall kan en organisation helt övergå till Webex Calling (fas 2) på en mycket kort period (veckor eller månader). Detta dokument är avsett att täcka båda faserna (fas 1 - samexistens och fas 2 - fullständig övergång).
Det är möjligt att vissa organisationer kan upprätthålla en samexistens med dubbla samtalskontrolldistribu tioner på obestämd tid utan planer på att någonsin helt övergå till molnsamtal.
Det andra övervägandet är hur du överför användare, enheter och mjuka klienter från den lokala samtal skontrollen till molnsamtalskontrollen. Det rekommenderade tillvägagångssättet är en trefasad övergång . Figuren Rekommenderad 3-fasövergång nedan delar upp detta tillvägagångssätt i de tre faserna.
Förmigrering: Denna fas fokuserar på att göra både Webex och Unified CM miljöer redo för migreringen. Det handlar inte om att anropa specifik planering eller konfigurationer utan fokuserar på att slutföra aktiviteter som kan göras nu och innan ett Webex Calling migreringsprojekt startar. Målet är att bygga grunden för de två miljöerna för att förbereda sig för migreringen.
Migreringsförberedelser: I den här fasen inleds insatsen för att förbereda migreringen till Webex Calling. Här måste affärsmässiga och tekniska krav ses över och uppdateras. Gör inte bara ett lyft och skift av det som för närvarande distribueras med Unified CM utan omdefiniera istället de affärsmässiga och tekniska krav som ditt företag behöver idag och i framtiden genom att utnyttja kraften i. Webex Calling Dessutom är detta fasen där du kommer att slutföra din design, konfigurations planering och migreringsplanering/schema.
Migrering (utrullning och avveckling): Den här fasen sker den faktiska migr eringen av användare, enheter, telefonnummer och mjuka klienter. Som diskuterats ovan kan denna fas slutföras för alla samtidigt (flash-cut) eller över flera ändringsfönster (fas ad skärning). Slutanvändarnas antagningsplaner, utbildning och kommunikation är avgörande, så dina användare är medvetna om förändringarna, hur man använder den nya samtalsplattformen och vet när förändringen kommer att ske. Det sista steget är att avveckla all lokal UC-infrastruktur som inte längre används.
Förmigreringsfasen innehåller aktiviteter (obligatoriska, rekommenderade och valfria) som du kan börja arbeta med omedelbart. Det rekommenderas att slutföra dessa förr snarare än senare och helst innan ditt projekt börjar. Vissa av aktiviteterna kan ta längre tid att slutföra, så att starta dem tidigare hjälper det att effektivisera ditt faktiska migreringsprojekt.
Figuren Fö re migrationsaktiviteter nedan belyser fem specifika kategorier av aktiviteter som är relaterade till en Webex Calling migration.
Förbereda
Affärsmässiga och tekniska krav
När du planerar en migrering från till är det viktigt att noggrant samla in både tekniska och affärsmässiga krav under planeringsfasen. Detta steg säkerställer att migreringen överensstämmer med organisationens operativa mål och tekniska kapacitet, vilket minimerar risker och störningar.
Varför det är viktigt att samla krav:
-
Anpassar affärsmålen: Att förstå affärsbehov hjälper till att skräddarsy migreringen för att stödja viktiga arbetsflöden, användarupplevelse och tillväxtplaner.
-
Säkerställer teknisk kompatibilitet: Att identifiera tekniska krav tidigt förhindrar integrationsproblem med befintlig infrastruktur, nätverk och slutpunkter.
-
Underlättar resursplanering: Tydliga krav hjälper till att uppskatta tidslinjer, kostnader och nödvändiga resurser exakt.
-
Minskar risker: Ti dig upptäckt av potentiella utmaningar möjliggör proaktiva lösningar, vilket minskar driftstopp och serviceavbrott.
Affärskrav
Typiska affärskrav inkluderar:
-
Antal användare och platser som ska migreras
-
Önskade funktioner och tjänster (exempel samtalsdirigering, röstbrevlåda, konferenser, automatiska sköer, samtalsköer)
-
Policyer för efterlevnad och säkerhet
-
Budgetbegränsningar och kostnadsförväntningar
-
Användarutbildning och supportbehov
-
Överväganden om migrering och affärskontinuitetsöverväganden.
Att samla in önskade funktioner och tjänster är ett viktigt steg för att säkerställa att det nya systemet uppfyller affärsbehov. När du samlar in dessa krav är det viktigt att inte bara överväga vad som för närvarande är konfigurerat utan försöka samla in de faktiska kraven från de affärsenheter som ska använda systemet. Annars finns det en risk att planen bygger på långfristiga antaganden. Se till att utvärdera ytterligare eller förbättrade funktioner som är tillgängliga i som kanske inte finns i, till exempel molnbaserade samtal, avancerade samtalsköer, , och. Detta hjälper till att utnyttja alla fördelar med molnplattformen.
När du utvärderar den aktuella konfigurationen i, är det viktigt att inse att inte alla befintliga inställningar kan förbli nödvändiga på grund av förän derliga krav under hela systemets livscykel. Fokus bör ligga på att identifiera och behålla endast de konfigurationer som överensstämmer med de nuvarande och framtida behoven för implementeringen.
Fokusera mer på vad du behöver än vad du har.
Efterlevnads- och säkerhetspolicyer är viktiga överväganden under migreringen från Webex Calling till för att säkerställa att det nya molnbaserade kommunikationssystemet följer juridiska, regelmässiga och organisatoriska standarder.
-
Regelefterlevnad: Organisationer måste verifiera att de uppfyller branschspecifika bestämmelser som GDPR, HIPAA eller SOX, och ta itu med krav på datasekretess, lagring och hantering, samt landsspecifika mandat relaterade till datalägenhet, vägtullförbikoppling och medielokalitet.
-
Datasäkerhet: Säkerställa att röst- och signaldata krypteras både i transit och i vila för att skydda mot avlyssning eller obehörig åtkomst.
-
Åtkomstkontroller: Definiera och verkställa användarautentisering, auktorisering och rollbaserad åtkomst för att förhindra obehörig användning av kommunikationsresurser.
-
Granskning och övervakning: Im plementera loggnings- och övervakningsfunktioner för att spåra åtkomst och användning för efterlevnadsrevisioner och utredningar av säkerhetsincidenter.
-
Policyanpassning: Anpassa migreringen till befintliga företags säkerhetspolicyer, inklusive slutpunktssäkerhet, nätverkssegmentering och planer för hantering av incidenter.
-
Leverantörssäkerhetsförsäkring: U tvärdera Ciscos säkerhetscertifieringar och efterlevnadsintyg för att säkerställa tillförlitlighet.
Att hantera dessa efterlevnads- och säkerhetspolicyer under planeringsfasen hjälper till att minska riskerna, undvika rättsliga påföljder och upprätthålla integriteten och konfidentialiteten för kommunikationen under och efter migreringen.
Användarutbildning och supportbehov är viktiga komponenter under migreringen från till för att säkerställa en smidig övergång och användaradoption. Viktiga överväganden inkluderar:
-
Utbildningsprogram: Utveckla skräddarsydda utbildningar för olika användargrupper (slutanvändare, administratörer, helpdesk-personal) för att bekanta dem med funktioner, användargränssnitt och nya arbetsflöden.
-
Dokumentation: Tillhandahåll tydliga och lättillgängliga användarhandböcker, vanliga frågor och snabbreferens material, inklusive nyheter och olika resurser och steg-för-steg-instruktioner före och efter (i video- eller snabbguideformat), för att stödja användarna när de an passar sig till den uppdaterade upplevelsen efter migreringen.
-
Ändringshantering: Kommunicera förändringar proaktivt för att hantera användarnas förväntningar och minska motståndet.
-
Supportstruktur: Upprätta ett dedikerat supportteam eller eskaleringsväg för att hantera användarproblem snabbt under och efter migreringen.
-
Pågående utbildning: Planera för kontinuerliga utbildningsuppdateringar när nya funktioner eller uppdateringar släpps i.
-
Feedbackmekanismer: Implementera kanaler för användare att rapportera problem och ge feedback för att förbättra utbildnings- och supportprocesser.
Att hantera dessa utbildnings- och supportbehov under planeringsfasen hjälper till att minimera störningar, ökar användarnas förtroende, och maximerar fördelarna med att migrera till.
Tekniska krav
Flera viktiga tekniska krav måste samlas in och dokumenteras för en lyckad migrering från till, inklusive detaljer för
-
Nätverksberedskap och bandbreddskapacitet
En omfattande nätverksbedömning är avgörande för att säkerställa att din befintliga infrastruktur kan stödja den nya Webex Calling miljön. Detta inkluderar:
-
Bandbreddsanalys: U tvärdera aktuell och projicerad bandbreddsanvändning för att hantera röst-, video- och datatrafik utan trängsel.
-
Quality of Service (QoS): Implementer a QoS-policyer för att prioritera rösttrafik och minimera latens, jitter och paketförlust.
-
WAN- och internetanslutning: Kontrollera att WAN-länkar och internet anslutningar uppfyller kraven för molnbaserade samtal, inklusive redundans och failover-funktioner.
-
Brandvägg- och NAT-konfiguration: Se till att brandvägg- och NAT-inställningar tillåter nödvändig signalering och medietrafik för.
-
-
Integration med befintligt system
Sömlös integration med befintliga affärssystem är avgörande för användarupplevelse och kontinuitet i arbetsflödet:
-
Katalogtjänster: Utvär dera integrationen med en företagskatalog för automatiserad användarprovisionering och autentisering.
-
CRM och affärsapplikationer: Identifiera integrationspunkter med kund relationshanteringssystem och andra affärskritiska applikationer.
-
Äldre PBX-samverkan: Plan ering för samexistens eller stegvisa migrerings strategier om några äldre telefonisystem kommer att finnas kvar under övergången.
-
-
Slutpunktskompatibilitet och etablering
Alla slutpunkter inklusive skrivbordstelefoner, softphones och mobila enheter bör utvärderas med avseende på kompatibilitet :
-
Enhetsstöd: Bekräfta att befintliga IP-telefoner och enheter stöds av eller identifiera nödvändiga ersättningar.
-
Provisionsprocesser: Upprätt ande av automatiserade eller strömlinjeformade provisionering smetoder för effektiv onboarding av slutpunkter.
-
Firmware- och programuppdateringar: Planerar nödvändiga uppdateringar för att säkerställa driftskompatibilitet och säkerhet.
-
-
Säkerhetskonfigurationer och krypteringsstandarder
Säkerhet är av största vikt i molnkommunikation:
-
Kryptering: Genomför end-to-end-kryptering för signalering och mediaströmmar, i linje med Ciscos bästa säkerhetspraxis.
-
Autentisering och åtkomstkontroll: Implementera säkra autentiseringsm ekanismer (som SSO, multifaktorautentisering) och detaljerade användaråtkomst kontroller.
-
Överensstämmelse: Säkerställa att lösningen uppfyller relevanta regelverk och brans chstandarder (t.ex. GDPR, HIPAA).
-
Säkerhetsövervakning: Integrera med SIEM-verktyg och ställa in varningar för potentiella säkerhetsincidenter.
-
| Krav | Viktiga överväganden |
|---|---|
| Nätverksberedskap och bandbredd | Bandbredd, QoS, WAN/Internet, brandvägg/NAT |
| Integration med befintliga system | Katalog, CRM, PBX, E-post/kalender |
| Slutpunktskompatibilitet och etablering | Enhetsstöd, provisionering, firmwareuppdateringar |
| Säkerhetskonfigurationer och kryptering | Kryptering, autentisering, efterlevnad, säkerhetsövervakning |
| Användarutbildning och förändringshantering | Utbildningsprogram, dokumentation, förändringskommunikation |
| Nummerportabilitet och uppringningsplan | Nummermigrering/portering, uppringningsplanöversättning |
| Tredjepartsintegrationer | Personsökning, kontaktcenter, fax, analoga enheter |
Nätverksberedskap och krav
Nätverksberedskap är avgörande för en lyckad migrering till alla molnbaserade samtalslösningar som. Dålig nätverksplanering kan leda till försämrad samtalskvalitet, tappade samtal och missnöjda användare. Kunderna måste göra en nätverksbedömning innan de migrerar till. Det rekommenderas att bekräfta tillgänglighet för nätverksbandbredd för förväntad samtals volym, se till att kraven på servicekvalitet (QoS) uppfylls och förstå de olika portar som måste öppnas i kantbrandväggen (erna).
Tillförlitlig nätverksanslutning med tillräcklig servicekvalitet (bandbredd, paketförlust, RTT) är ett grundkrav för att säkerställa bästa möjliga användarupplevelse från början till slut för alla röst- och videokompatibla slutpunkter, klienter och applikationer som använder.
Kunder och partners har tillgång till anslutningsalternativ utöver OTT-internet (Over-the-Top) som kan optimera anslutningen till att inkludera Webex Edge Connect. Mer information om Webex Edge Connect- designdetaljer finns i Cisco Preferred Architecture for Webex Edge Connect forWebex Meetings, Calling Multi-Tenant och Dedikerad instans.
Kunder kan använda cScan för nätverksbedömning som ger information om kundens nätverkskvalitet, hur många samtal som kan upprättas, latens och så vidare. Mer information om cScan-verktyget finns i Använda cScan för att testa Webex Calling nätverk skvalitet.
Tänk på följande checklista för att säkerställa att nätverket är klart för migrering till:
-
Bandbreddsplanering
Beräkna samtidiga samtal per webbplats för att säkerställa att du har tillräckligt med uppströms och nedströms bandbredd och inkludera utrymme för annan affärskritisk trafik och framtida tillväxt.
Tabellen för beräkning av bandbredd för samtalstyp visar de samtalstyper som är tillgängliga med en distribution tillsammans med codec och maximal bandbredd som krävs för varje samtalstyp. Webex Calling Som visas i tabellen för beräk Webex Calling ning av bandbredd för samtalstyp som krävs för ljudsamtalsbandbredd för varje samtalstyp kan beräknas med hjälp av följande allmänna formel:
Antal förväntade samtidiga samtal* Bandbredd per samtal baserat på codec = Obligatorisk nätverksgenomströmning.
Tabell 2. Webex Callingsamtalstyp bandbredds beräkningar Samtalstyper Codec - bandbredd Bandbreddsberäkningar /Skrivbordstelefon -> OPUS - 70 kbps Antal samtidiga samtal* 70 kbps = Nödvändig nätverksgenomström ning /Skrivbordstelefon -> Skrivbordstelefon OPUS — 70 kbps Antal samtidiga samtal* 70 kbps = Nödvändig nätverksgenomström ning /Skrivbordstelefon -> PSTN via LGW G.711 — 80 kbps Antal samtidiga samtal* 80 kbps = Nödvändig nätverksgenomström ning /Skrivbordstelefon -> PSTN via Cloud PSTN (t.ex. Cisco-samtalsplan) G.711 — 80 kbps Antal samtidiga samtal* 80 kbps = Nödvändig nätverksgenomström ning /Skrivbordstelefon -> Enterprise via LGW G.722 — 80 kbps Antal samtidiga samtal* 80 kbps = Nödvändig nätverksgenomström ning /Skrivbordstelefon -> röstbrevlåda OPUS — 70 kbps Antal samtidiga samtal* 70 kbps = Nödvändig nätverksgenomström ning Genom att summera den samtidiga nödvändiga nätverksgenomströmningen per samtal styp kan det totala potentiella bandbreddskravet för en specifik plats bestämmas.
Alla samtalsben är alltid förankrade på åtkomstSBC: erna. För att bestämma den nödvändiga internetbandbredden för en viss plats behöver inte bara samtal mellan lokaliseringar beaktas, utan också samtal inom lokaliseringen och samtal till och från en lokal gateway på den platsen. Till exempel skulle ett samtal mellan två MPP-telefoner behöva upp till 2 x 70 kbps full duplex på platsens internetåtkomst.
Tabellen med exempel på Webex Calling bandbreddsberäkning visar ett exempel på en fullständig bandbre ddberäkningsövning, förutsatt att alla enheter finns på samma plats.
Tabell 3. Webex Calling exempel på bandbreddsberäkning Samtalstyper Antal samtidiga samtal Total bandbredd Webex-app/Skrivbordstelefon → Webex-app 15 2 * 15 * 70 kbps = 2 100 kbps Webex App/Skrivbordstelefon → Skrivbordstelefon 15 2 * 15 * 70 kbps = 2 100 kbps Webex-app/skrivbordstelefon → PSTN via LGW 50 2 * 50 * 80 kbps = 8 000 kbps Webex-app/skrivbordstelefon → PSTN via Cloud Connect för Webex Calling 0 0* 80 kbps Webex-app/skrivbordstelefon → Företag via LGW 15 2 * 15 * 80 kbps = 2400 kbps Webex App/Skrivbordstelefon → Webex Calling Röstbrevlåda 5 5 * 70 kbps = 350 kbps Totalt antal samtal/bandbredd 100 samtal 14 950 kbps/14,95 Mbps -
Alla bandbreddsvärden i tabellerna ovan hänvisar till IP-bandbredd. Länkbandbredden är högre beroende på WAN-inkapslingar.
-
Bandbredden i tabellerna ovan är för ljud samtal. För bandbredd för videosamtal stöder Webex App och MPP 8845/65-telefonerna H.264-video med maximal upplösning på 720p med en maximal bandbredd på 1 500 kbps per samtal. Mängden bandbredd som förbrukas när som helst under samtalet kommer dock att fluktuera baserat på variabel bithastighet som är inneboende i videokommunikation.
-
-
Servicekvalitet (QoS)
Implementera QoS-policyer i din lokala miljö för att prioritera trafik i realtid och se till att QoS upprätthålls över switchar, routrar och brandväggar.
-
Latens-, jitter- och paketförlustmål
Följande trösklar rekommenderas för optimal röst kvalitet när samtal går over-the-top (OTT) och över internet:
-
Latens - mindre än 100 ms enkelriktad
-
Jitter - mindre än 10 ms
-
Paketförlust - 0,5% eller mindre.
-
-
Brandvägg och NAT
Se till att brandväggen är konfigurerad för att tillåta trafik enligt listan i artikeln som finns på Portreferensinformation för Webex Calling. Tillåt dessutom åtkomst till domäner och IP-intervall som anges i samma guide och undvik SIP ALG eftersom det stör SIP-signalering. Medietrafik via proxyer bör undvikas.
-
DNS och NTP
Säkerställ korrekt DNS-upplösning av domäner och pålitliga NTP-servrar för att synkronisera enhetsklockor för TLS-certifikatverifiering och loggning.
-
Failover-planering
Tänk på befintliga leverantörsdataanslutningar (MPLS, SD-WAN och så vidare) och planera generellt för direkt internetåtkomst på varje plats i din distribution. Planera redundanta internet länkar där hög tillgänglighet krävs. Eftersom du kommer att konsumera molnbaserade tjänster är pålitlig internet anslutning med tillräcklig bandbredd ett bas krav. Du bör överväga att göra denna övergång om din organisations platsers internetanslutning (er) i allmänhet inte är tillförlitlig med låg latens och tillräcklig genomströmning upp och nedströms.
-
Webbplatsens överlevnadsförmåga
Webbplatsens överlevnad säkerställer att ditt företag alltid är tillgängligt, även om din nätverksanslutning går sönder. Site Survivalability använder en gateway i ditt lokala nätverk för att tillhandahålla en reservsamtalstjänst till slutpunkter på plats för situationer där nätverksanslutningen bryts. Överväg webbplatsens överlevnad med en lokal Sur vivalability Gateway (SGW) om affärskrav kräver kontinuerliga samtal i händelse av nätverksavbrott. För mer information om webbplatsens överlevnadskontroll, se Webbplatsens överlevnadsförmåga för. Webex Calling
Konfigurera molnansluten UC
Cloud Connected UC (CCUC) är en molnbaserad hanterings- och analyslösning utformad för att ge centraliserad synlighet, administration och insikter för distributioner både lokalt (somUnified CM) och molnet (). Det fungerar som en bro mellan traditionella lokala miljöer och Ciscos molntjänster och stöder organisationer under hela migrerings resan från till.
Under övergången till, CCUC spelar en viktig roll för att effektivisera migreringsprocessen genom att underlätta in samlingen av omfattande data från den befintliga Unified Communications-distributionen. CCUC hjälper till med viktiga övergångsuppgifter som migrering av enheter, funktioner och användar kontakter, samt automatisering av firmwareuppdateringar för IP-telefoner som stöds. Genom att tillhandahålla centraliserad synlighet och hantering hjälper CCUC till att säkerställa en smidigare och effektivare migreringsupplevelse.
Cisco rekommenderar starkt att CCUC distribueras och distribueras tidigt i övergångsprojektet, helst före eller under förberedelsefasen. Detta möjliggör de insikter och funktioner som behövs för att noggrant utvärdera, inventera och planera för efterföljande migrering saktiviteter och för att starta din resa till och framtida hybridfunktioner.
Bedömning av den nuvarande miljön
En viktig aktivitet i planeringen av migreringen är att bedöma den aktuella lokala miljön och distributionen. Detta ger insikter om vilka potentiella förändringar som kan krävas för att framgångsrikt övergå till. Det låter dig också bedöma de viktigaste elementen i plattformen jämfört med den befintliga lokala distributionen. Du kan använda den här informationen för att identifiera vilka specifika uppgifter som krävs för övergången och vilka ändringar du vill göra för att uppfylla dina affärs- och tekniska krav och användningsfall.
Följande aspekter är viktiga att granska som en del av denna insats.
Licensiering
Att förstå den nuvarande licensstrukturen för den befintliga distributionen är nyckeln när du förbereder dig för att migrera till. Utför en licensbedömning av följande områden i din befintliga lokala Cisco- lösning.
-
Plattform
Möjligheten att fullt ut formulera vad som för närvarande är licensierat på din kärnplattform kommer att vara avgörande när du arbetar med ditt kontoteam eller partner för att bestämma den bästa vägen till flex licenser. licensieras med flexlicensiering. Mer information om flexlicensiering finns i Cisco Collaboration flex plan.
-
Användare och enheter
Identifiera vilken licenskategori dina befintliga användare och enheter behöver. Detta kommer att användas för att avgöra vilken typ av licens som krävs för användarna och enheterna. erbjuder flera licenstyper, inklusive Professional- och Standard-licenser för användare och Professional- och gemensamma områdeslicenser för arbetsytor. Mer information om enhetslicensiering finns i databladet som finns på Enhetslicensiering.
-
Lokal gateway
Om Cisco Unified Border Element (CUBE) krävs för PSTN-åtkomst för denna övergång måste CUBE-licensiering också övervägas. CUBE-licensieringsöverväganden behandlas senare i detta dokument.
Platser/platser
Antalet och typerna av platser (stora centrala, regionala, filialer osv.) inom din befintliga distribution bör beaktas när du planerar denna övergång. En fullständig förståelse för de befintliga distributionsplatserna kommer att hjälpa till med strategisk planering för en framgångsrik övergång, särskilt när det gäller att bestämma vilka platser som ska migreras och i vilken ordning. Att i detalj förstå krav på uppringningsplan (numrering, uppringningsvanor, begränsningsklasser osv.), nätverksanslutning och bandbredd (Internet, WAN, LAN) och PSTN-åtkomst (lokal eller centraliserad, IP eller TDM) för varje webbplats kommer att vara avgörande när migreringsbeslut fattas. Mer information om vanliga distributionsmodeller och viktiga överväganden finns i informationen om distributionsmodeller för samarbete som finns i SRND för samarbete.
En annan viktig distributionshänsyn när du övergår till är platstillgänglighet. har olika funktioner, prenumerationer och enheter som är tillgängliga beroende på var distributionen finns. Mer information om geografisk tillgänglighet finns i Var är Webex tillgängligt? .
Slutligen är det viktigt att förstå vilken inverkan övergången till kommer att få på andra samarbetstjänster. Baserat på syftet med detta dokument är det allmänna antagandet att om befintliga samarbetstjänster utanför samtalsbelastningen ska bibehållas, förväntas övergången till fas 1-hybriddistributionen som nämns ovan. Exempel på samarbetstjänster som kan kräva hybriddistribution inkluderar lokalt kontaktcenter som ännu inte har migrerats till Webex kontaktcenter och snäva integrationer i system som personsökningssystem och fakturering. Mer information om övergången till ytterligare samarbetsarbetsbelastningar och tjänster finns i Samarbetsövergångar.
Inventera befintliga enheter/kunder
Innan övergången påbörjas är det viktigt att inventera dina befintliga hårdvaru- och mjukvaruslutpunkter. Om du har en fullständig lista över enhetstyper/modeller, maskinvaruversioner, operativsystemstyper och kvantiteter för mjuka klienter kan du planera på ett adekvat sätt för övergången av enheterna och minska effekten för de enheter som inte kan migreras till molnsamtal. Inventeringen bör användas för att bestämma vilka enheter som ska övergå och de enheter som ska bytas ut före över gången.
Skrivbordstelefoner
För ljud- och videobordstelefoner stöds endast skrivbordstelefoner i serien 6800, 7800, 8800 och 9800-serien. Detta är en delmängd av Cisco IP-telefoner som stöds med. Det finns vissa modeller och versioner av 6800, 7800 och 8800 telefoner som inte kan användas med. Mer information om vilka modeller och maskinvaruversioner som stöds finns i Enheter som stöds för Webex Calling.
Cisco 6800-seriens IP-telefoner kan inte uppgraderas från Enterprise-firmware till Multiplatform (MPP) firmware, vilket krävs för. Därför måste alla 6800-telefoner som är registrerade för firmware för företag ersättas med en 6800 MPP-modell eller med en annan telefonmodell som stöds.
Cisco 7800- och 8800-seriens IP-telefoner måste uppgraderas till MPP- firmware (Multiplatform Phone) innan övergången och registreras till. Om du vill ta reda på vilka 7800- och 8800-modeller och maskinvaruversioner som stöder MPP-firmware, se Konvertera IP-telefoner i Cisco 7800- och 8800-serien mellan Enterprise - och MPP-firmware.
8845, 8865 och 8865NR har nått slutet av försäljningen och rekommenderas inte att migreras till.
Äldre versioner av 8800-seriens telefoner (8811, 8841, 8851, 8851NR, 8861) rekommenderas inte att använda med. Webex Calling Telefoner med hårdvaruversioner VID 14 eller tidigare kommer att registrera sig med men kan uppleva vissa prestandaproblem på grund av hårdvaran.
9800-seriens bordstelefoner kör PhoneOS, som stöder både och registrering. Därför kan dessa telefoner övergå till utan en firmwareuppgradering.
Alla andra IP-telefoner måste bytas ut mot en 6800-, 7800-, 8800- eller 9800-serietelefoner som stöds av. Webex Calling Mer information om vilka IP- och skriv bordstelefoner som stöds finns i artikeln på Enheter som stöds för Webex Calling.
Videoslutpunkter
Personal- och rumsvideoslutpunkter, inklusive Cisco Board-serien, Room-serien och Desk- serien, kan SIP-registreras naturligt till. Alla dessa slutpunkter som behöver ringa ljud- och/eller PSTN-samtal kräver en samtalslicens:
-
Delade enheter i konferensrum, mötesutrymmen etc. kräver antingen en Professional Workspace eller Workspace-licens.
-
En slutanvändares personliga enhet kräver en professionell licens eller standardlicens.
Bestäm hur många videoslutpunkter som är registrerade på och används för att ringa ljudsamtal. Det är möjligt att vissa av videoslutpunkterna endast kan användas för att ansluta till möten eller ringa SIP-videosamtal. I båda fallen måste slutpunkterna fortfarande migreras till innan servrarna tas ur drift, men detta hjälper till att avgöra hur många av dem som behöver licenser för att fortsätta ringa telefonsamtal.
-
När videoenheter flyttas från registrering till ändras URI för dessa slutpunkter eftersom de nu är molnregistrerade.
-
Telefonmodellerna 8845, 8865 och 8875 är personliga video telefoner som stöds med.
Mjuka klienter
Det är den enda mjuka klienten som stöds av, till skillnad från Unified CM vilken stöder både Webex-appen och Jabber, och är den nya standardmjuka klienten för slutanvändare.
Beroende på driftsättningsläget (erna) som implementerats för Jabber (endast IM-, telefon- och/eller fullständiga UC-lägen) kan du också behöva överväga övergången av meddelandets- och/eller mötes arbetsbelastningarna från Jabber till. Den kan distribueras i telefonläge om den kommer att användas som en samtalsklient eller den kan distribueras som full Webex Suite om andra arbetsbelastningar, t.ex. Webex Messagingoch/ellerWebex Meetings, övergår till appen med samtal.
Det förbättrar slutanvändarens upplevelse genom att tillhandahålla AI-funktioner som ljud/videointelligens, samtalstranskription och andra. Mer information finns på https://www.webex.com/all-new-webex.
Innan du flyttar användare till måste du överföra sina Jabber-klienter till. Du har två alternativ för att slutföra denna övergång.
-
Innan du överför dem till
-
När du överför dem till.
För att underlätta den första övergången till, rekommenderas att använda alternativ 1 och flytta användare till med samtal först. Detta ger användarna tid att bekanta sig med den nya applikationen medan de fortfarande använder den befintliga lokala samtalsplattformen. När du är redo att flytta användare till konfigurerar du dem för att registrera sig på molnsamtalsplattformen.
För mer information om dessa två alternativ, se Migreringsresa - ett eller två steg? .
En fullständig lista över enheter som stöds för finns i Enheter som stöds för Webex Calling.
Verifiera enhetens behörighet
Som nämnts tidigare stöder en delmängd av Cisco IP-telefoner och kräver en annan firmwaretyp för telefonerna i 7800- och 8800-serien. Unified CMtelefoner kör Enterprise-firmware medan telefoner kör Multiplatform Phone (MPP) firmware. Det rekommenderas att kontrollera vilka registrerade telefoner som är berättigade att uppgradera till MPP-firmware under förberedelsefasen. Detta ger dig tid att ersätta icke-kvalificerade telefoner med en av de telefonmodeller som stöds eller att identifiera en alternativ plan, som att flytta en användare till endast Webex-appen.
Control Hub har ett inbyggt verktyg som heter Migrera din telefon till för att hjälpa till att avgöra om telefonerna är berättigade Webex Calling. När du använder det här verktyget för att kontrollera enhetens behörighet väljer du alternativet Migrering Generera endast enhetslicens.
Med det här alternativet kan du ladda upp en CSV-fil som innehåller telefonerna så att du kan kontrollera behörigheten för varje telefon. Genom att välja det här migreringsalternativet lägger det inte till telefonerna eftersom du fortfarande är i förberedelsefasen och inte är redo att göra detta ännu. Mer information finns i Migrera telefonen till Webex Calling.
Det är möjligt att vissa av telefonerna kan komma tillbaka med en okänd behörighet. Detta beror vanligtvis på att det inte går att validera viss information om telefonen i back-end-systemet. För alla telefoner som har status O känd har du två alternativ för att verifiera om de är berättigade att uppgradera till MPP-firmware.
-
Kontrollera varje telefon manuellt och verifiera modell- och hårdvaruversionen (PID VID)
7800/8800 telefonetikett med modell- och maskinvaruversionsinformation -
Använd Ciscos verktyg för beredskap för IP-telefoner
Ladda ner verktyget från https://github.com/joemar2/mpp_readiness_check.
Detta verktyg är inte ett officiellt Cisco-verktyg och det stöds inte heller TAC. Den har bästa ansträngnings stöd men är gratis att använda.
Det här verktyget måste köras på en dator som är lokal och kan komma åt servrarna och IP-telefonerna. Den har ett alternativ för att aktivera webbåtkomst på IP-telefonerna, vilket rekommenderas och behövs för att få bästa resultat. Därför bör den användas under lediga timmar för att undvika störningar för slutanvändarna. Utgången från verktyget ger en rapport som listar vilka av telefonerna i 7800- och 8800-serien som är berättigade att uppgradera till MPP-firmware. Eftersom den direkt kommer åt telefonen kan den verifiera de okända enheterna som rapporterades från Control Hub-verktyget.
Rapport om Cisco IP-telefonberedskapsverktyg
Användare
Ett av de viktigaste förberedelsestegen för att säkerställa att du har en lyckad migrering är korrekt användarprovisionering. Du måste planera ordentligt för alla användare även om du gör en stegvis migrering. Användare måste vara etablerade för något av följande:
-
Implementera med samtal
-
Distribuera med
-
Konfigurera tjänster för en användare
-
För att göra användare sökbara i katalogen (klicka för att ringa, Användarkontaktinformation, telefonkatalogsökning).
Vi rekommenderar att du tillhandahåller alla användare före eller i början av projektet. Detta inkluderar användare som fortfarande använder Unified CM för sin samtalsplattform är oberoende av sin samtalsenhet (IP-telefon, Jabber,). När användare migreras till (och/eller) uppdaterar du deras licenser för att aktivera de tjänster de behöver. Genom att etablera alla företagsanropande användare innan övergången påbörjas gör det möjligt för en användare som har övergått till eller att söka i katalogen efter en anropande företagsanvändare som fortfarande är på Jabber och/eller på. Detta säkerställer att övergångna användare kan hitta andra användares kontaktinformation och ringa till dem med hjälp av kataloguppslaget.
Sökningen i figur katalogen visar ett exempel på en användare som söker efter en annan användare. Sökresultaten visar användarens kontaktinformation och kan vara för en användare som fortfarande är på Jabber och eller för en användare som har övergått till och/eller.
Bestäm sedan vilka av de befintliga lokala samtalsanvändarna som ska övergå till. Om alla eller ett stort antal användare kommer att övergå rekommenderas det att flytta användare i grupper för att säkerställa att projektteam, IT-personal och supportpersonal kan hantera övergången och eventuella problem som kan uppstå. Du bör också avsätta lite tid för att tillhandahålla inledande information och utbildningar för att förbereda användarna för denna övergång. Användar övergångsgruppering kan göras baserat på en mängd olika kriterier, inklusive platsen eller webbplatsen som användare tilldelas, användaravdelningar eller till och med användartyper (kunskapsarbetare, chefer, mobila arbetare och så vidare).
Om användarna i distributionen till exempel är uppdelade på tre huvudplatser, New York (NYC), San Francisco (SFC) och Research Triangle Park (RTP), kan en användarövergångsplan se ut som den plan som beskrivs i Användarövergångsplan för platstabell.
| Användarwebbplats/plats | Information och utbildningar före övergången | Övergångsperiod | Stöd efter övergången |
|---|---|---|---|
| NYC (1 525 användare) | Vecka den 1 april | 15 april — 27 april | Vecka 29 april |
| SFO (1 600 användare) | Vecka Maj 6 | Maj 20 — Maj 31 | Vecka den 3 juni |
| RTP (1 275 användare) | Vecka den 3 juni | 17 juni - 28 juni | Vecka 1 juli |
En annan viktig faktor är att överföra användare tillsammans som har beroenden mellan varandra . Detta kan inkludera, men är inte begränsat till, följande:
-
BLF-övervakning
-
Samma jaktpilot/grupp
-
Dela rader
-
Ingår i samma samtalsupphämtningsgrupp
-
Använda samma call-park-nummer
-
Intercom
-
Administratör/Exec.
Du kan granska konfigurationen (GUI eller export) eller använda verktyget Migration Insights för att identifiera användargrupperna med dessa beroenden.
PSTN-anslutning
kan komma åt PSTN på tre sätt: Ciscos samtalsplaner, Cloud connect för (tidigare Cloud Connected PSTN) och lokal PSTN (lokal gateway). En enskild plats som definieras inom kan dock endast tilldelas ett enda PSTN-alternativ.
Lokalt PSTN med en lokal gateway (LGW) är en viktig del av övergångsstrategin. Det ger anslutning mellan den lokala distributionen och/eller PSTN och plattformen. stöder både Cisco och certifierade tredjepartssessionsgränskontroller (SBC) som kan användas som lokal gateway. För den senaste listan över SBC som stöds, se Lista över SBC som stöds.
stöder upp till 250 samtidiga samtal från en enda lokal gateway som är registreringsbaserad och mer än 250 samtidiga samtal från en enda lokal gateway som är certifikatbaserad. Certifikatbaserade lokala gateways kan stödja upp till 6500 samtidiga samtal, men detta baseras på vilken typ av anslutning den lokala gatewayen måste ha (Over-the-Top vs interconnect peering) och SBC-modellen som den lokala gatewayen distribueras på. Dessa gränser är i huvudsak standardräkningsgränsen för både lokala gateway-baserade PSTN-samtal och samtal mellan platser mellan och slutpunkter. Mer information finns i Kom ma igång med lokal gateway.
Alla samtal som överskrider denna gräns avvisas med 403 förbjudet. Det aktiva röstkommandot Visa samtal kan köras på den lokala gatewayen när som helst för att bestämma det totala antalet aktiva samtal.
Dåliga nätverksförhållanden mellan en lokal gateway och åtkomstSBC kan begränsa signalanslutningens prestanda, vilket leder till en ännu lägre gräns för samtidiga samtal. Envägs latens mellan den lokala gatewayen och datacentret bör inte överstiga 100 ms och jitter bör vara mindre än 10 ms medan paketförlusten är mindre än 0,5%.
Funktioner och funktionsanvändning
Vid bedömning av den aktuella miljön är det viktigt att identifiera och granska vilka funktioner som är konfigurerade. Dessutom är det viktigt att förstå användningen av funktionerna så att du kan (åter) definiera dina affärs- och tekniska krav för din distribution.
För att avgöra vilka funktioner som är konfigurerade analyserar du konfigurationen. Detta är alla statiska data som ställs in när en funktion eller inställning konfigureras på systemet. Följande alternativ kan användas för att slutföra denna analys:
-
Granska konfigurationen i admin GUI
-
config export - bulkexport eller AXL
-
verktyg för migreringsinsikter (rekommenderas)
-
Cisco tredjepartspartnerverktyg (rekommenderas).
För att analysera funktionsanvändning effektivt är det viktigt att undersöka dynamiska systemdata som användning, registreringar och samtal saktivitet. Olika analysverktyg och instrumentpaneler ger insikter i dessa mätvärden, vilket möjliggör en omfattande förståelse av systemets prestanda och kapacitet, vilket stöder informerat beslutsfattande under migrering och optimering. Följande alternativ kan användas för att slutföra denna typ av analys:
-
Granskning av råa CDR-poster
-
Granskning av Unified CM RTMT-data
-
Migration Insights verktyg med CDR-data
-
Granskning av molnansluten UC-analys i
-
Samtalsvolym
-
Registrerade slutpunkter
-
(CAC) platser
-
Stomutnyttjande.
-
-
Ciscos partnerverktyg från tredje part.
Cisco rekommenderar att du börjar med verktyget Webex Control Hub Migration Insights för den här analysen. Du importerar din export.TAR-fil och Unified CM CDR-filer (valfritt, men krävs för analys av funktionsan vändning) till verktyget. Verktyget genererar följande CSV-baserade rapporter som kan användas för att starta analysen:
| Rapportens namn Rapportbeskrivning |
|---|
| ImportedDataBulk.csv
Alla användare och enheter från Unified CM data |
| DeviceEligibility.csv
Identifierar enheter som är berättigade att migrera till Webex Calling (IP-telefoner, Room OS- enheter, ATA och tredje part) |
| DevicePoolNumbers.txt Lista över alla nummer i en viss enhet spool |
| HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv Detaljer om enheter och användare som ska migreras tillsammans baserat på delade linjer, jakt pilot, samtalskö, samtalspark och samtalsupphämtningsgruppskonfiguration |
| HuntGroupMigrationInsight.csv Detaljerad information om tilldelade jakt linjer, linjegrupper och tillhörande agenter |
| SharedlineGroupMigrationReport.csv Översikt över hur telefonnummer (katalognummer) delas mellan användare |
| Rapportens namn Rapportbeskrivning |
|---|
| FeatureUsageBasedDeviceEligibilityReport.csv Information om behörighet för enhetsmigrering baserat på funktionsanvändning |
| FeatureUsageWithLastUsageDateReport.csv Användningsantal för antalet gånger jaktpilot (er) och samtalskö (er) har anropats tillsammans med det senaste användnings datumet |
| UserWorkspaceLastUsage.csv Senaste användningsdatum för användare och arbetsytor för både mjuka klienter och hårdtelefoner |
| DIDUsageReport.csv DID-användning för både tilldelade och otilldelade DID |
Mer information om rapporterna Migration Insights finns i Migrering sinsikter.
Om du behöver mer information om funktionerna och användningen efter att ha granskat informationen i Migration Insights-rapporterna rekommenderar Cisco att överväga ett av Ciscos tredjepartsmigreringsverktyg för partners och/eller att granska konfigurationerna i användargränssnittet eller i konfigurationsexportdata.
Cisco-integrationer: Unity-anslutning UCCX UCCE
Röstbrevlådan är en integrerad del av erbjudandet och inbyggd i lösningen. kan inte integreras med en lokalbaserad röstbrevlådelösning som Unity Connection eller Unity Connection Express. Ytterligare, det finns inget inbyggt sätt att migrera befintliga röstmeddelanden eller hälsningar för Unit y-anslutning till den inbyggda röstbrevlådetjänsten som är tillgänglig med. Vissa av Ciscos tredjepartspartners migreringsverktyg har kapacitet att migrera en del av dessa data. Mer information om röstbrevlåda för finns i Konfigurera och hantera röstbrevlådeinställningar för en användare. Webex Calling
stöder också delade röstbrevlådor och faxbrevlådor. Mer information finns i Hantera en delad röstbrevlåda och inkommande fax box för. Webex Calling
har en inbyggd Auto Attendant-funktion som ingår som en del av kärnplattformen. Den här funktionen möjliggör övergång av din Unity Connections samtalshanterare och automatisk skötarfunktion. Verktyget Control Hub, Migrera funktioner frånUnified CM, stöder migrering av Unity-anslutningskonfigurationer till Auto-skötare. Mer information om hur du använder det här verktyget finns i Migrering av enheter och funktioner från Unified CM tillWebex Calling.
Samtalsinspelning
innehåller två alternativ för samtalsinspelning utan extra kostnad.
-
Webex samtalsinspelning
-
Dubber Go inspelning (partnererbjudande) - en integration mellan och dubber där alla inspelade media förvaras säkert i molnet.
Inkluderad inspelningsalternativ tabell belyser några viktiga funktioner i de två samtalsinspelningsalternativen som är tillgängliga utan extra kostnad.
| Webex | Dubbel Go |
|---|---|
| Tillgängligt för alla användare | Tillgängligt för alla användare |
| Obegränsat antal inspelningar | Obegränsat antal inspelningar |
| 1 års lagringstid* | 30-dagars lagringsperiod |
| 100 GB lagringsutrymme per organisation | - |
| Compliance-ansvariga kan komma åt och hantera samtalsinspelningar | - |
| API: er för att hantera inspelningar | - |
Administratörer kan konfigurera och hantera användarnas åtkomst till sina samtalsinspelningar
|
Endast användare kan komma åt och hantera sina inspelningar
|
Om din organisation kräver ytterligare inspelningsfunktioner som inspelning av efterlevnadssamtal, längre lagringsperioder, mer lagring, AI-analys och/eller administratörsåtkomst, finns det betalda erbjudanden eller tillägg från både Cisco och tredjeparts inspelningsleverantörer. Mer information om inspelningsleverantörer, konfigurationer och tilläggspartnertjänster finns i Hantera samtalsin spelning för Webex Calling.
Integrationer från tredje part
stöder en mängd olika tredjepartsinte gr ationer inklusive men inte begränsat till SBC: er för lokala gateways, IP-telefoner, intercom-telefoner, högtalare/personsökare, ATA, etc. Förutom dessa tredjepart sen heter, Webex Calling stöder olika tredjepart slösningar för kundsupport, analys, inspelning, fakturering etc. Mer information om tredje part slösningar finns i Webex App Hub.
Planera
Projektplan på hög nivå
När man utvecklar en projektplan på hög nivå för migrering från till, är det viktigt att fastställa tydliga faser och milstolpar som överensstämmer med både affär smål och tekniska krav. Planen bör inledas med en omfattande utvärderings fas, inklusive insamling av detaljerade tekniska och affärsmässiga krav, samt identifiering av intressenter och definition av framgångskriterier. Viktiga överväganden inkluderar resur sallokering, tidslinjeuppskattning, riskhantering, och kommunikationsstrategier för att säkerställa att alla parter är informerade och engagerade under hela migreringen. Dessutom bör planen innehålla valideringskontrollpunkter som pilottestning och stegvis utrullning för att minimera störningar och möjliggöra justeringar baserade på feedback.
Exempel på element som ska inkluderas i projektplanen är:
-
Definiera omfattningen av migreringen (t.ex. vilka användare, enheter och funktioner som ska övergå)
-
Schemalägga utbildningar för slutanvändare och supportteam
-
Samordna bedömningar av nätverksberedskap, och
-
Planering för cutover-aktiviteter med fallback-alternativ. Det är också viktigt att integrera efterlevnads- och säkerhetsgranskningar samt stöd- och optimerings faser efter migrering.
Genom att strukturera projektplanen med dessa överväganden kan organisationer bättre hantera komplexitet, minska riskerna och uppnå en smidigare övergång till.
Migrationsresa - ett eller två steg?
kräver att användare använder den för att ringa mjukklienten. Därför, om några användare fortfarande använder, har du två alternativ när du kan flytta dem till. Du kan antingen göra en användarmigrering i ett steg eller en användarmigrering i två steg.
Alternativ 1: Migrering av användare i ett steg
I en enda stegsmigrering övergår användarna från till samtidigt som de övergår från Unified CM till. Det här alternativet är vanligtvis för kunder med ett litet antal användare att migrera och kan hantera att flytta både användarens mjuka klient och samtalstjänst till samtidigt. Siff ran Användarens samtalstjänst, mjukklient och telefon migrerar till samtidigt nedan belyser denna typ av migration. Med det här alternativet kommer en användare att ha följande slutfört samtidigt:
-
Samtalstjänster flyttade från till
-
Telefonnummer och tillägg flyttades från till
-
Mjuk klient övergick från Jabber till - kommer att registrera sig till
-
Telefonregistrering flyttades från till.
Detta kan fortfarande vara en stegvis migrering där grupper av användare flyttas vid olika tidpunkter, men när varje användare flyttas sker alla dessa samtidigt.
Alternativ 2: Migrering av användare i två steg
Det andra tillvägagångssättet är en tvåstegsmigration. I steg 1, användare övergår från till men stannar kvar för samtalstjänster. Sedan i steg 2 flyttas användare från Unified CM till. Det här alternativet rekommenderas för större kunder för att hantera slutanvändarändringarna och vill skilja användarens mjuka klientändring från ändringen av samtalstjänsten. Följande bild Migrera mjukklient; sedan migrera samtalstjänst, mjukklient och telefon till Webex Calling nedan belyser den här typen av migrering.
Steg 1
-
Mjuk klient övergick från till - kommer att registrera sig till.
Steg 2
-
Samtalstjänster flyttade från till.
-
Telefonnummer och tillägg flyttades från till.
-
registreringen flyttades från till.
-
Telefonregistrering flyttades från till.
Detta kan fortfarande vara en stegvis migrering där grupper av användare flyttas vid olika tidpunkter i båda stegen.
Vilket alternativ du väljer beror på hur du vill hantera användarnas övergång till och. Rekommendationen är att ta det i steg (alternativ 2). Detta gör att du kan minimera slut användarens ändringar på en gång och dela upp ansträngningen över olika delar av projektet. Men om du föredrar att användare bara påverkas en gång, är det också giltigt att använda Alternativ 1.
Om du tittar på den rekommenderade resan (alternativ 1) visar över gångskartan Jabber till Webex App på hög nivå nedan övergången på hög nivå för steg 1.
I det här steget övergår användarna från Jabber till för alla sina samtalstjänster. Samtalsplattformen är dock fortfarande Unified CM och kommer att registrera sina samtalstjänster till. Som framgår av övergångskartan Jabber till Webex App på hög nivå ändras inte den lokala infrastrukturen och fungerar på samma sätt som Jabber gör. Den enda förändringen är att den kräver en anslutning till.
Mer information om den här övergången finns i Jabber till Webex övergångskarta och distribu tionsguide under Klient på sidan Över gång för samarbete.
Unified CMtill över Webex Calling gångskart figur på hög nivå är över gången på hög nivå från till. Detta är steg 2 av den rekommenderade resan.
Om du väljer att använda enstegsmetoden gäller detta också.
I det här steget övergår användarna till i grupper. Vid denna tidpunkt börjar användarna använda för sina samtalstjänster, samtalsregistrering och IP-telefonregistrering.
Eftersom användare flyttar i grupper kommer Enterprise-användare att delas mellan de två samtalspl attformarna under övergången. Fas 1 in Unified CMtill över Webex Calling gångskart figur på hög nivå visar detta tillstånd. Under denna fas krävs planering för hur man hanterar samtal mellan användare på de två plattformarna och hur PSTN-samtal kommer att dirigeras. Varje gång en grupp användare övergår till krävs uppringningsplaner och uppdateringar av samtalsrutning på, och den eller de lokala gatewayerna.
När alla användare, mjuka klienter och enheter har övergått till (fas 2) kan all lokal UC-infrastruktur tas bort och avvecklas.
Utformning
Val av region
är tillgänglig globalt och levereras från redundanta datacenter i flera regioner: USA (Dallas, Chicago), Kanada (Vancouver, Toronto), Europa (Frankfurt, Amsterdam), Storbritannien (London, Manchester), Australien (Melbourne, Sydney), Japan (Tokyo, Osaka), Saudiarabien (Riyadh, Jeddah) och Indien (Mumbai, Chennai). Media-POPs tillhandahåller medietjänster för att optimera mediernas rundturstider. Singapore-datacentret används till exempel för att optimera media rund turstiderna för kunder i asiatiska länder där rundturstiderna till antingen Australien eller Japan kan vara suboptimala. Datacentren är sammankopplade med en multi-gigabit och helt redundant ryggrad. Siff ran globalt distribuerade datac enter visar en översikt över alla datacenter. För den senaste listan över tillgängliga datacenter, se Datacenterplatser för Webex Calling.
Varje kund är etablerad på en av instanserna. All provisioneringsinformation för den kunden lagras i den instansen och SIP-signaleringen för alla slutpunkter och lokala gateways som är etablerade för den kunden är knuten till den instans kunden är etablerad på. Eftersom det är svårt att ändra det ursprungliga regionvalet är det viktigt att beakta alla relevanta faktorer som en del av besluts processen som leder till regionvalet. För att undvika överdriven signalering rundtursfördröjning är det viktigt att tidigt i övergångsprocessen bestämma vilken instans som ska användas. Cisco rekommenderar att du väljer den instans som ger de lägsta signaleringstiderna för det största antalet användare inom distributionen.
För tillgänglighet i länder, se Var är Webex tillgängligt? .
Platser
För att förbereda för tillhandahållande av platser måste den information som krävs för alla migreringsmål samlas in. Informationen som behövs för varje plats sammanfattas i Information som ska fångas för varje plats.
| Informationen | Kommentera |
|---|---|
| Förlängningsintervall | Varje plats i kan ha tillägg som börjar med olika siffror. En siffra måste sparas för
styrsiffran mellan olika platser (till exempel 8) och en för PSTN-
styrsiffran (till exempel 9). Inget förlängningsområde kan börja med någon av
dessa två siffror. Alla förlängningsintervall på alla platser måste vara lika långa. |
| DID-intervall | - |
| PSTN-styrsiffra | - |
| Webbplatskod | Alla webbplatskoder på alla platser måste vara unika och ha samma längd. |
| Huvudnummer | När du skapar en plats måste två DID: er etableras. Ett som
huvudnummer (till exempel för att tilldelas en automatisk mottagningstjänst) och ett för röstbrevlå
deportalen. Bestäm en DID för röstbrevlådans nummer. |
| Röstbrevlådanummer | |
| Antal licenser | Obligatoriska licenser efter typ inklusive Standard, Professional, Workspace, Ruttlista, Utgående samtalsplan. |
| Samtidiga samtal under den hektiska timmen | Summan av samtidiga samtal mellan enheter och mellan enheter och den lokala gatewayen (PSTN och samtal till enheter). Behövs för att bestämma den nödvändiga bandbredden för internetåtkomst. |
| Land | - |
| Tidszon | - |
| Språk | - |
| Kontakt (Namn, Telefon, E-post) | - |
| Adress (Gatuadress, Stad, Stat, Postnummer) | - |
| Räddningstjänstens fysiska avsändningsplats för slutpunkter | Enhetens avsändningsplats som används för nödsamtal inkluderar i allmänhet följande: byggnadsadress, byggnadsadress+våningsnummer, byggnadsadress+ svitnummer eller byggnadsadress+våningsnummer+kontor/kubiskt nummer. |
| Unik fysisk nätverksplats per enhet för räddningstjänster | Fysisk nätverksplats för nödsamtal omfattar i allmänhet följande: switch/switchport för trådbundna enheter, BSSID (Wireless Access Point) Basic Service Set Identifiers (BSSID) för trådlösa anslutna enheter och/eller lokala IP-delnät för slutpunktsenheter. |
PSTN
När kunderna utformar en driftsättning har kunderna tre primära PSTN-anslutningsalternativ: Cisco C alling Plans (en molnlevererad PSTN-tjänst som hanteras av Cisco), Cloud Connec ted PSTN Providers (CCPP, där leverantörer levererar PSTN-tjänster via molnet) och lokalt PSTN (där lokala gateways ansluter företagsnätverket till PSTN). Med införandet av PSTN-trunking för hybriddistributioner (för mer information, se PSTN-trunking för hybrid Webex Calling distributioner vid PSTN-trunking) får organisationer ytterligare flexibilitet i sin migreringsstrategi. Den här funktionen gör det möjligt för kunder att flytta sitt PSTN till CCPP i början av övergångs resan och börja övergå till moln-PSTN för användare, samtidigt som de utnyttjar CCPP för att upprätthålla PSTN-tjänsten för användare som förblir på Cisco under en stegvis migrering.
Detta hybridtillvägagångssätt gör det möjligt för organisationer att flytta utvalda användargrupper till molnet först, utan att omedelbart göra en översyn av hela telefonimiljön. Det introducerar dock ytterligare komplexitet och risk, särskilt när det gäller att anpassa befintlig samtalsroutningslogik för att stödja den nya arkitekturen. Interoperabilitet med äldre applikationer, till exempel faxservrar, kontaktcenter eller personsök ningssystem, kräver också noggrant övervägande. Viktiga tekniska utmaningar kan vara att säkerställa sömlös end-to-end-codec-förhandling och DTMF-signalering (Dual-Tone Multi-Frequency) över den blandade miljön, samt validering av kompatibilitet med specialiserade telefonfunktioner. Korrekt planering och testning är avgörande för att minimera störningar och upprätthålla tillförlitliga rösttjänster under hela migreringsprocessen. Dessutom är kommersiella överväganden viktiga, eftersom hybridtrunkning kräver en användningsl icens som baseras på antalet samtidiga samtal mellan den lokala miljön och Cloud Connec ted PSTN Provider (CCPP).
Alternativt kan organisationer välja att behålla sin lokala PSTN-anslutning under hela övergångsfasen. I det här scenariot kan migrering till CCPP utföras på två sätt: som en enda, samordnad cutover för alla användare och platser när migreringen är klar, eller stegvis, med PSTN-migrering per plats när användare flyttas till. Detta tillvägagångssätt kan hjälpa till att effektivisera samexistensen och upprätthålla kontinuitet för äldre integrationer, men det introducerar flera operativa komplexiteter. Bland dessa är utmaningar relaterade till nummerportering, såsom behovet av exakt samordning av nummerportorder, potentiella förseningar, och leverantörsinställda begränsningar som ett tak på antalet samtidiga portförfrågningar eller begränsningar för att portera delmängder av stora antal block. Organisationer måste noggrant planera sin PSTN-övergångsstrategi och ta hänsyn till dessa logistiska överväganden för att undvika serviceavbrott och säkerställa en smidig migreringsupplevelse.
Figuren Migrering till CCCP i början jämfört med att behålla lokalt PSTN visar de två PSTN- migreringsalternativen som förklaras ovan. Illustrationen till vänster visar scenariot där alla lokala användare och program använder moln anslutna PSTN-tjänster via en lokal trunk och en lokal gateway som ansluter den lokala till medan illustrationen till höger visar scenariot där den befintliga lokala PSTN förblir på plats och användare använder lokal PSTN via den lokala gateway-anslutningen mellan lokala Webex Calling enheter . och. Under övergången kan platser bytas till med Cloud Connected PSTN.
I båda scenarierna använder samtal mellan lokal och användare den lokala gateway-anslutningen. Anslutningen mellan lokalt och måste utformas och dimensioneras i enlighet med det förväntade antalet samtidiga samtal och den nödvändiga redundansen.
Uppringningsplan
För att uppnå sömlös interoperabilitet mellan och under migreringsperioden måste en omfattande uppringningsplanarkitektur utvecklas och implementeras på båda plattformarna. Denna uppringningsplandesign med dubbla plattformar säkerställer konsekvent samtals dirigering, nummeröversättning och funktionsinsyn, vilket gör det möjligt för användare på båda systemen att kommunicera utan försämring av tjänsten eller störningar i användarupplevelsen under hela samexistensfasen.
Lokal uppringningsplan i
Under övergången för att möjliggöra samexistens mellan enheter som är registrerade på Unified CM och på företaget måste uppringningsplanen ändras så att åtminstone följande krav kan uppfyllas:
-
+E.164 uppringning från till
-
Anslutningsuppringning från till (inom webbplatsen men även mellan platser om tilläggsområdena är unika)
-
Förkortad uppringning mellan webbplatser från till
-
Tvingad uppringning på nätet från till
-
Återuppringning från katalogen för missade samtal till destinationer på
-
PSTN-anrop från till PSTN om under övergången används lokalt PSTN för
-
PSTN-anrop från till om under övergången PSTN-trunking för hybriddistributioner används för att ge PSTN-åtkomst till lokala användare via Cloud Connect för
-
Tvingad på nätet från till
-
Anslutningsuppringning från till (mellan webbplatser).
Om något av ovanstående inte stöds uppringningsvanor före övergången, till exempel finns det ingen förkortad uppringningsvana mellan webbplatser, behöver de inte nödvändigtvis inför as under övergången.
Figuruppringnings planen för bästa praxis visar den bästa metoden för uppringningsplan enligt beskrivningen i Preferred Architecture for Cisco Collaboration 12.x Enterprise On-Premises Deployments, CVD. Viktiga egenskaper hos detta tillvägagångssätt inkluderar:
-
Enkel partition för+E.164 katalognummer
-
Kärnrouting baserad på+E.164 ruttmönster
-
Normalisering av alla uppringningsvanor till+E.164 med hjälp av översättningsmönster
-
Användning av översättningsmönster som anropar sökutrymmesarv (alternativ Använd upphovsmannens anro pssökutrymme inställ t på översättningsmönster).
Till exempel kommer PSTN-uppringning (9+1+10D) från en enhet i SJC som är etablerad med söku trymme för linjeanrop SJCinternational först att matchas av översättningsmönstret 9.1 [2-9] XX [2-9] XXXXXX som normaliserar det uppringda partens nummer till +E.164. Den sekundära uppsö kningen använder sedan samma anropande sökutrymme SJCinternational igen (anropar sökutrymmes arv) och +E.164-siffriga strängen matchas antingen av ett +E.164-katalognummer i DN-partitionen eller av ett av PST N- ruttmönstren i partitionen USPSTNnational eller SJCpStnLocal. Förkortade interna och intersite-uppringningsvanor implementeras av översättningarna i ESN- och SJCTO E 164-partitionen. Medan ESN- partitionen är en global partition (tillgänglig för telefoner på alla platser) är SJCTOE16 4-partitionen endast tillgänglig för användare på plats SJC. Detta förutsätter överlappande förlängningsintervall.
Det första steget för att aktivera samtal från till är att se till att+E.164-destinationer dirigeras därefter. Detta kan uppnås genom att lägga till en partition i uppringningsplanen, lägga till +E.164 ruttmönster för alla destinationer till den partitionen, och slutligen lägga till partitionen till alla anropande sökutrymmen som representerar klasser av tjänster som måste kunna nås. Att skapa en dedikerad partition krävs för att möjliggöra skapande av en differentierad klass av tjänster för samtal som härrör från. För att undvika samtalslingor bör sökutrymmet för inkommande samtal på trunken från den lokala gatewayen inte ha åtkomst till partitionen.
Som visas i figur +E.164 routing tillWebex Calling, för att möjliggöra routing från till för en plats med+E.164 DID-intervall +1 221 555 2XXX och platskod 121, måste ett brådskande rutt mönster som matchar detta+E.164-intervall läggas till i partitionen.
Om inget platsspecifikt val av lokal gateway krävs kan du istället för att använda en ruttlista med en lokal ruttgrupp som mål för ruttmönster som pekar på en enda ruttgrupp etableras med den lokala gatewayen som enda medlem och sedan pekar ruttmönstren på en enda ruttlista med den här ruttgruppen som enda post.
För att aktivera förkortad uppringning mellan platser till platsen läggs det nödvändiga ruttmönstret 8121.2XXX till partitionen. För platser som ska övergå till ett uppringningsnormaliseringsmönster 8121.2XXX som normaliserar ESN-uppringning till +E. 164 kan det redan finnas i ESN-partitionen. I så fall verkar 8121.2XXX vara överflödig, men så snart alla DN:er på respektive plats har migrerats över till 8121.2XX X-uppringningsnormaliseringsmönstret kan översättningsmönstret tas bort och sedan möjliggör ruttmönstret 8121.2XXX ESN-uppringning även för användare som endast använder anknytning i det området.
Med dessa uppringningsplanändringar kan samtal till platsen göras inte bara genom att ringa förkortat inter-site och +E.164. Internationell och nationell PSTN-uppringning är också möjlig eftersom dessa uppringningsvanor först normaliseras till +E.164 genom de redan befintliga översättningsmönstren för uppringningsnormalisering och sedan dirigeras till genom att matcha ruttmönstret +E.164 i partitionen.
+E.164-ruttmönstermatchningen på platsens DID-intervall kan etableras medan alla DID fortfarande är på. Den bästa matchningsmönstermatchningsalgoritmen ser till att när ett nummer som är värd är uppringt så matchar +E.164-katalognumret som tillhandahålls på bättre än det jokertecknade +E.164-ruttmönstret som pekar på så att samtalen utvidgas till en linje på och inte skickas till.
uppringningsplan
Varje användare har ett tillägg och/eller ett +E.164-telefonnummer. Tilläggslängden är en fast global inställning: alla tillägg i en distribution har samma längd. Anslutningsuppringning kan användas mellan användare både inom en plats och mellan platser. Förkortad uppr ingning mellan webbplatser (det senare fallet) fungerar bara om det uppringda tillägget är unikt.
Om förkortad uppringning mellan platser mellan platser är ett krav men det finns överlappningar mellan tillägg som tilldelats på olika platser, måste en företagsspecifik numreringsplan skapas genom att föregå tilläggen med en åtkomstkod en webbplatskod. Mer information finns i Preferred Architecture for Cisco Collaboration 15 On-premises Deployments, Designöversikt finns på Ciscos föredragna arkitekturer för samarbete.
Anslutningslängden, uppringningsbeteendet mellan lokaliseringsanordningarna, prefixlängden för uppring ning mellan lokaliseringar och styrsiffran i routingprefixet för uppringning mellan lokaliseringar konfigur eras i inställningarna för samtalstjänsten i:
-
Platsroutningsprefixlängd: Prefixlängd inklusive styrsiffran. K rävs endast om en företagsnummerplan måste upprättas som alternativ förkortad uppring ningsmetod mellan företag.
-
Styrsiffra i routingprefix: Styrsiffra för förkortad uppringnings vana mellan företag. Överlappningar med första siffran på valfri plats och plats för utgående uppringningssiffror bör undvikas. K rävs endast om en företagsnummerplan måste upprättas som alternativ förkortad uppring ningsmetod mellan företag.
-
Intern förlängningslängd: Standardlängd på förlängningar. Kan vara vilket värde som helst mellan två och tio.
När telefonnummeruppringning eller uppringning med betydande företagsnummer (styrkod, platskod, anknytning) krävs från en lokal samtalskontroll till och den lokala samtalskontrollen skickar ett anknytning som uppringnings-id, måste du också ange parametern Maximal okänd anknytningslängd i avsnittet Samtalsdirigering mellan och lokaler för att säkerställa att uppströmssamtal från den lokala samtalskon trollen till kan klassificeras som lokala samtal korrekt. -
Tillåt nummeruppringning mellan platser: Växla för att aktivera/inaktivera anslutningsuppringning mellan platser. Det här alternativet bör endast aktiveras om alla tillägg inom organisationen är unika. Om alternativet är inaktiverat måste företagets betydande nummer (styrkod, webbplatskod, anknytning) eller telefonnummer ringas mellan platser.
De tre första parametrarna används främst för att bygga en uppringningsplan för telefoner för att minimera mellan siffriga timeouts när du använder off-hook-uppringning. Avvikelser från dessa globala inställningar är fortfarande möjliga (Exempel - tillägg med en annan längd kan etableras), men ett varningsmeddelande dyker upp i Control Hub och uppringning från telefoner kan kräva blockering av uppringning för att undvika konflikter inom den förinstallerade uppringningsplanen.
Tabellen Enterprise numrering sexempel visar ett exempel på tre platser där tilläggsområdena för två platser, NYC och RTP, är identiska. Upprättande av ett företags numreringsschema med styrsiffra mellan platser 8, följt av en tresiffrig webbplatskod, och det fyrsiffriga tillägget skapar en icke-överlappande förkortad uppringningsvana mellan webbplatser.
| Webbplatsen | Förlängningsintervall | Webbplatskod | Enterprise-sortiment |
|---|---|---|---|
| NYC | 2XXX | 202 | 8 202 2XXX |
| SFO | 3XXX | 203 | 8 203 3XXX |
| RTP | 2XXX | 204 | 8 204 2XXX |
För att möjliggöra en smidig övergång bör uppsättningen uppringningsvanor för användare före och efter övergången till idealiskt vara densamma. För att förbereda övergången för varje plats måste DID-intervall och förlängningsintervall (eller förkortade uppringningsvanor inom webbplatsen) dokumenteras. Baserat på denna information måste styrsiffran mellan anläggningarna väljas.
Tabellen F asta längdförlängningsintervall visar ett exempel på tre platser och förlängnings intervall med fast längd. Eftersom överlappande uppringningsvanor måste undvikas är det viktigt att se till att den första siffran i intervallet inte matchar styrsiffran för förkortad uppringning mellan platser för alla förlängningsintervall. Om till exempel 8 väljs som styrsiffra för uppringning mellan platser, då kan inget tilläggsområde på någon plats börja med 8. Vanligtvis matchar tilläggen på en viss plats de sista siffrorna i DID: erna som tilldelats den platsen. För att undvika konflikter kan den första siffran i förlängningen ändras. Om till exempel DID i intervallet +1 408 555 8XXX används på en plats, kan istället för att använda 8XXX som förlängningsområde 7XXX användas för tilläggen på den webbplatsen
| Webbplatsen | Förlängningsintervall | Förlängningar | Webbplatskod | Enterprise-sortiment |
|---|---|---|---|---|
| NYC | 2XXX | 2XXX | 202 | 8 202 2XXX |
| SFO | 8XXX | 7XXX | 203 | 8 203 7XXX |
| RTP | 1XX | 11XX | 204 | 8 204 11XX |
Sjusiffriga uppringningssträngar som ringts på en enhet som använder den amerikanska uppringningsplanen överlappar med ett sjusiffrigt mönster för lokal uppringning i den förinstallerade amerikanska uppringningsplanen. För att undvika överlappningar mellan alla uppringningsvanor på nätet och utanför nätet (PSTN) kan en obligatorisk extern åtkomstkod användas på den platsen. Om det befintliga företagsnumreringsschemat och motsvarande förkortade uppringning mellan platser överlappar mönster i den nationella urtavlan, kan under övergången till numreringsschemat för att undvika överlappningar också ändras till en längre eller kortare form. Det enklaste sättet att uppnå detta är att lägga till en extra fyllnadssiffra i numreringsschemat. Det nya längre schemat för uppringning mellan webbplatser behöver bara antas av användare som redan migrerats till. Användare som fortfarande är på kan fortsätta att ringa sju siffror. I det här fallet måste företagets uppringningsplan se till att förkortad sjusiffrig uppringning från Unified CM till omvandlas till antingen +E.164 eller till det förkortade uppringningsformat som används på. Detta måste göras innan du skickar samtalet till den lokala gatewayen.
Den sjusiffriga uppringningen Tabellövergång visar ett exempel på denna omnumrering. I det här exemplet använder förkortad uppringning mellan platser styrsiffra 8 följt av en tvåsiffrig webbplatskod och ett fyrsiffrigt tillägg. För att undvika sjusiffrig förkortad uppringning mellan platser för platser på, kan webbplatskoderna enkelt ändras till tre siffror genom att föregå en godtycklig fyllnadssiffra (8 i exemplet) till de två siffriga webbplatskoderna som används i så att uppringning mellan platser från telefoner använder styrsiffran 8 följt av fyllnadssiffran 8, den gamla tvåsiffriga webbplatskoden och det fyrsiffriga tillägget. Användare på behöver inte komma ihåg nya webbplatskoder; de behöver bara komma ihåg att använda 88 som prefix för uppringning mellan webbplatser istället för 8 på.
| Webbplatsen | Förlängningar | Webbplatskod | Enterprise-sortiment | Webbplatsens ode | Enterprise ange |
| NYC | 2XXX | 22 | 8 22 2XXX | 822 | 8 822 2XXX |
| SFO | 8XXX | 23 | 8 23 7XXX | 823 | 8 823 7XXX |
| RTP | 1XXX | 24 | 8 24 11XX | 824 | 8 824 11XX |
I ett scenario med olika företagsnummerformat aktiverade och om företagsnummer presenteras som information om den uppringande parten för samtal från till (till exempel - Samtal från enheter utan DID), är det viktigt att också implementera en m appning mellan de olika nummerformaten för information om den uppringande parten för att säkerställa att återuppringningen fungerar. Denna mappning kan uppnås genom att använda samtalspartens transformationsmönster på trunken mellan och den lokala gatewayen.
Inspelning
En väldesignad samtalsinspelningslösning kräver noggrann övervägning av flera viktiga designelement för att säkerställa att den överensstämmer med organisatoriska mål, lagkrav och tekniska begränsningar. Två av de mest kritiska besluten handlar om val av leverantör och regionval, som båda kan behöva skräddarsys globalt och åsidosättas på specifika platser, baserat på affärsbehov.
1. Val av leverantör av samtalsinspelning
Att välja lämplig leverantör av samtalsinspelning är grundläggande för att uppfylla affär smålen och säkerställa att funktionerna anpassas i hela organisationen:
-
Ur@@ val av global leverantör: Organisationer utser vanligtvis en primär samtalsinspelningsleverantör på global nivå, vilket säkerställer enhetlighet i funktionsuppsättning, efterlevnad och support på alla platser
-
Platsbaserade åsidosättningar: I scenarier där specifika platser eller regioner har unika affärsbehov eller lagstadgade krav kan det vara nödvändigt att åsidosätta det globala leverantörsvalet och ange alternativa leverantörer för dessa platser. Denna flexibilitet stöder olika efterlevnadsmandat och lokala operativa behov
-
Affärskrav: Valet av leverantör bör styras av en bedömning av företagets drivkrafter såsom regelefterlevnad (exempel - MiFID II, HIPAA), kvalitetssäkring, tvistlösning eller utbildningsbehov
-
Tillgänglighet för funktioner: Leverantörer bör utvärderas utifrån deras förmåga att leverera nödvändiga funktioner, till exempel realtidsövervakning, sök- och uppspelningsfunktioner, kryptering, lagringspolicyer, integration med analysplattformar och stöd för olika samtalstyper (inkommande, utgående, interna).
2. Val av region
Att bestämma regionen där samtalsinspelningar lagras och bearbetas är avgörande för efterlevnad och prestanda:
-
Globalt regionval: Som standard kan organisationer välja en enda region för lagring av samtalsinspelningar för att förenkla hantering och styrning
-
Platsbaserade regionåsidosättningar: När lagar om dataredighet eller företagspolicyer kräver det kan det vara nödvändigt att åsidosätta den globala regioninställningen för specifika platser, så att samtalsinspelningar lagras och behandlas inom de geografiska gränserna som krävs.
-
K@@ rav på datalägenhet: Designen måste ta hänsyn till internationella och lokala dataskyddsbestämmelser (som GDPR, CCPA eller landsspecifika mandat) som kan diktera var och hur samtalsinspelningar behålls.
En annan kritisk aspekt som ska tas upp vid planering och utformning av en samtalsinspel ningslösning för är uppskattningen av lagringsbehov. Noggrann prognos för lagringsbehov är avgörande för att säkerställa att tillräcklig kapacitet finns tillgänglig för att stödja pågående affärs verksamhet, upprätthålla efterlevnad och undvika störningar i tjänsten.
Flera viktiga parametrar bör beaktas vid bestämning av det förväntade lagringsbehovet:
-
Volymen av inspelade samtal: Bedöm det förväntade antalet samtal som kommer att spelas in inom ett visst tidsintervall (t.ex. per dag, vecka eller månad). Detta inkluderar inte bara externa samtal utan även intern kommunikation, om det krävs enligt affärspolicy eller myndighetsmandat
-
Genomsnittlig samtalstid: Beräkna den typiska längden på inspelade samtal, eftersom längre samtal tar mer lagringsutrymme. Variationer i samtalslängd mellan olika avdelningar eller användargrupper bör också beaktas i uppskattningen
-
L@@ agringsperiod: Definiera hur lång tid inspelningar måste behållas, vilket ofta dikteras av organisationens policyer eller externa regler (till exempel branschspecifika efterlevnadsstandarder). Längre lagringsperioder ökar det totala lagringskravet
-
Tillväxtprognoser: Tänk på förväntad tillväxt i samtalsvolymer eller utvidgning av inspelningsomfånget, vilket kan bero på affärsskalning, nya lagkrav eller introduktion av ytterligare användare eller platser.
Genom att noggrant analysera dessa parametrar kan organisationer utveckla en robust lagringsstrategi som säkerställer skalbarhet, kostnadseffektivitet och regelefterlevnad för deras samtalsinspelningslösning. Det är också tillrådligt att regelbundet granska och justera lagringsalloker ingar när användningsmönstren utvecklas över tiden.
Nödsamtal
Kravet att dirigera ett nödsamtal till lämpligt sändningscenter är ett krav för alla samtalstjänster som erbjuder PSTN-tjänst. Med, dirigeringen av nödsamtal är inbyggd i lösningen och inkluderar stöd för alla nationella nödnummer i de länder som stöder. Routningen av ett nödsamtal baseras på den plats som definieras inom och PSTN-åtkomstmetoden för platsen. Nödnumren i är fördefinierade och specifika för det land som användarna och enheterna är distribuerade i.
Det finns två sätt att leverera nödsamtal. Det finns en grundläggande rutttjänst för nödsamtal och en förbättrad rutningstjänst för nödsamtal. Den grundläggande rutttjänsten för nödsamtal använder ett administratörsvalt nummer för att identifiera platsen och samtalsvägen för att nå räddningstjänsten. För grundläggande nödsamtal är samtalsvägen vanligtvis via kundens PSTN-alternativ för den platsen . har också förbättrad ruttning av nödsamtal utformad för distributioner i USA och Kanada som har krav på regelefterlevnad som kräver användning av en rikstäckande leverantör för att leverera nödsamtal till rätt sändningscenter.
Alla kunder bör åtminstone distribuera den grundläggande konfigurationen för nödsamtal. Grundläggande nödsamtal kräver att minst ett kundägt +E.164-nummer tilldelas varje plats som definieras i. För grundläggande nödsamtal, varje plats kommer att definieras av en gatuadress som polis, brand- eller ambulanstjänster skickas till vid nödsituationer. I de flesta fall är huvudnumret för platsen det bästa valet för att representera den fysiska platsen för nödsituationen. Vanligtvis samordnas tilldelningen av adressen till+E.164-numret med P STN-leverantören. Bilderna nedan visar tilldelningen av huvud numret som ska användas som nöduppringningsnummer för Richardson-platsen.
I de flesta situationer är en byggnadsadress tillräcklig för avsändningsadressen för platsen. Men om ytterligare platsinformation behövs för specifika användare eller enheter kan en administratör använda samma process som beskrivs ovan och tilldela dessa enheter till en specifik adress eller en mer exakt plats inuti adressen (som ett golv eller ett rum). Under Användarhantering i tillåter fliken Samtal att ett specifikt nummer kan användas för en användare och deras enheter för att få en specifik avsändningsadress. Följande bilder illustrerar hur ett specifikt nummer kan tilldelas en enhet. Administratören ansvarar för att numret som används av enheten har rätt leveransadress tilldelad den. Adres stilldelningen görs vanligtvis via PSTN-leverantören för den platsen.
För USA-baserade telefoniinstallationer som måste tillhandahålla förbättrade nödsamtal slösningar, använder RedSkys Horizon Mobility integrerad i för ruttning av nödsamtal. När du använder RedSky för samtalsdirigering måste en administratör registrera sig för ett konto via Cisco och konfigurera lämplig information i Samtal -> Serviceinställningar för att aktivera den här funktionen. När RedSky- tjänsten har aktiverats på systemnivå kommer en administratör att aktivera RedSky- tjänsten på varje platsnivå. Aktiveringen av Förbättrade nödsamtal på en plats aktiverar tjänsten för alla enheter som är tilldelade den platsen. Enheter som stöder förbättrat nödsamtal är Cisco MPP-telefoner, Cisco PhoneOS-telefoner och Ciscos.
Det finns två inställningar för att aktivera Förbättrat nödsamtal på en plats. Tillåt RedSky att ta emot information om nätverksanslutning och testsamtal bör användas för att verifiera att RedSky-konfigurationen för enhets- och infrastrukturmappningar är korrekt. Den här inställningen gör det också möjligt att placera testsamtal till 933 för att utföra plats verifiering med RedSkys IVR-system för att läsa upp platsen för den som ringer. Även om detta dokument inte täcker RedSky-konfigurationen för platsspårning, bör en administratör ALLTID testa sin platsupptäckt innan nöd samtal aktiveras för att dirigera till RedSky. När testningen har slutförts och verifierats som korrekt kommer administratören att dirigera samtal till RedSky genom att växla rutten nödsamtal till RedSky. Denna växling riktar alla nödsamtal för platsen till RedSky för leverans till telefonsvararen för platsen.
Inställningarna för förbättrade nödsamtal gäller även för klienter både lokalt och externt. När det är lokalt kan det spåras på samma sätt som skrivbordstelefoner spåras. När den är utanför lokal, användaren kommer att kunna ställa in sin plats dynamiskt direkt i. Mer information om nödsamtal finns i Förbättrat nödsamtal för.
Licensiering
Det finns flera alternativ för att tilldela licenser till användare.
Manuell tilldelning genom
Administratörer tilldelar licenser manuellt till enskilda användare via gränssnittet.
Administratörer kan redigera tjänstelicenser för enskilda användare och tilldela samtalslicenser direkt.
Mallar för automatisk licenstilldelning
Använd mallar för licenstilldelning för att automatiskt tilldela licenser till användare baserat på grupp- eller organisationsinställningar.
Automatisk licensiering kan göras genom katalogsynkronisering eller manuella användaruppdateringar, men användare måste ha ett giltigt +E.164-formaterat telefonnummer och telefonnumren måste finnas på en plats innan användaren tillhandahåller. Om villkoren inte uppfylls (t.ex. ogiltigt telefonnummer format) kommer licenser inte att tilldelas.
Masstilldelning via CSV-mall
Ladda upp en CSV-fil med användarinformation och licenstilldelningar för att lägga till eller ändra flera användare samtidigt.
CSV-import stöder att lägga till upp till 20 000 användare och tilldela licenser, men licenser kräver specifika fält som telefonnummer och tillägg.
API-baserad tilldelning
Använd API:er för att programmera tilldela licenser och hantera användare.
stöder API-operationer för användar- och licenshantering (People, SCIM 2.0 och Licenses API:er), som kan utnyttjas för automatisering av licenstilldelning. Licenser API tillåter samtidig tilldelning av licenser, telefonnummer och tillägg.
| Uppdragsmetod | Fördelar | Nackdelar |
|---|---|---|
| Manuell genom | Enkelt för få användare. Tillåter exakt och detaljerad kontroll över tilldelning av licenser. | Inte skalbar, tidskrävande Benägen för mänskliga fel vid manuell inmatning. |
| Automatiska licensmallar | Skalbar Minskar manuella fel Kan tillämpas på nya och befintliga användare. | Kräver giltiga telefonnummer och platser. Mer komplicerat att sätta upp Kräver också användargrupper per grupp användare med motsvarande licenskrav. |
| Massuppladdning av CSV | Effektiv för stora användaruppsättningar Tillåter samtidig tilldelning av licenser, telefonnummer och tillägg. | Kräver noggrann CSV-formatering Risken för fel om telefonnummer eller tillägg saknas eller är felaktiga. |
| API-baserad tilldelning | Automatiserbar, flexibel. Tillåter samtidig tilldelning av licenser, telefonnummer och tillägg. | Kräver utveckling och API-kunskap. |
Tabellen Användarprovisioneringsalternativ - sammanfattning sammanfattar användarprovisioneringsalternativ och deras fördelar och nackdelar. Den här översikten hjälper dig att välja den bästa licenstilldel ningsmetoden baserat på kundens organisationsstorlek, automatiseringsfunktioner och användarprovisionerings processer och krav.
När det är möjligt rekommenderar Cisco att tilldela samtalslicenser med hjälp av licensmallar. Detta kräver att för varje grupp användare som kräver en unik uppsättning licenser (Exempel - Standard vs. Professionell) en grupp med respektive gruppmedlemskap finns. Som diskuteras i avsnitten Användargrupper kan användargrupper definieras manuellt i eller synkroniseras från en företagskatalog. En kombination av båda metoderna är möjlig.
Användare som tillhör flera grupper får licenser från alla tilldelningar som tillämpas på alla deras grupper. Detta gör det möjligt att använda licensspecifika säkerhetsgrupper i företagskatalogen för att hantera licenstilldelning där den resulterande användarlicenstilldelningen styrs av föreningen av gruppmedlemskap.
Mer information finns i Ställa in automatiska licenstilldelningar i Control Hub och Konfigurera mallar för automatisk licenstilldelning för Webex Calling användare.
Licenskrav
Detta avsnitt omfattar endast relaterade licenser. Andra licenstyper (Exempel - Webex-enhetsregistrering, meddelanden, möten) täcks inte. Som en del av designprocessen måste licenskraven fastställas. Licensantal för följande licenstyper måste beräknas:
-
Standard: antal enskilda användare som kräver standardtelefonfunktioner.
-
Profession ell: antal användare och arbetsytor som kräver avancerade telefon funktioner. Virtuella linjer och gruppröstbrevlåda har rätt till ett förhållande på 1:1 för varje professionell licens. Därför, i sällsynta fall där antalet nödvändiga virtuella linjer eller gruppröstmeddelanden överstiger antalet användare och arbetsytor som kräver avancerade telefon funktioner, ytterligare professionella licenser måste redovisas.
-
Arbetsyta för gemensamt område: antal delade användningsområden eller gemensamma utrymmen som kräver standardsamtalsfunktioner.
-
Kundassistans: antal agenter och handledare som kräver Customer Assist-funktioner. Kundassistenten inkluderar Professional-licensen.
-
Ruttlistanrop: antal obligatoriska molnanslutna PSTN-samtal mellan lokala användare och/eller lokala specialiserade tredjepartsprogram.
-
Attendant Console: antal användare som behöver åtkomst till den skötande konsolklienten.
-
Cisco Calling Plan (Outbound Calling Plan): antal användare som behöver ett PSTN- nummer och/eller utgående PSTN-samtalsåtkomst för Cisco PSTN-tjänsten.
Det finns ingen dedikerad licenstyp för professionella arbetsytor. Professionella arbetsytor använder en Professional-licens.
Enbart arbetsytor med hot-desk erbjuder hotdesking-värdtjänsten och nödsamtal från hotdesk ing-värden och kräver ingen licens. Mer information finns i Lägga till och hantera enheter endast för hot desk.
Om du vill bestämma vilken licenstyp som krävs för varje användare och arbetsyta baserat på funktioner som behövs, se Funktioner tillgängliga efter licenstyp för Webex Calling.
För att skilja mellan funktionalitet som erbjuds av samtalsköer i kombination med den professionella licensen i motsats till kundassistans, se jämförelse av Webex Calling samtal skö och kundassistansfunktioner.
Tillhandahållande av användare
När du etablerar användare i Webex finns det flera alternativ tillgängliga, var och en anpassad till olika organisationsbehov och miljöer:
-
Manuell etablering: Administratörer kan lägga till och hantera enskilda användare direkt inom. Denna metod är enkel men bäst lämpad för små organisationer eller begränsade användar ändringar.
-
Massprovisionering via CSV: För större användarbaser kan administratörer importera och uppdatera användare i bulk genom att ladda upp CSV-filer till. Detta möjliggör effektiv hantering av upp till tusentals användare samtidigt.
-
Alternativ för katalogsynkronisering:
Directory Connector: Detta är ett automatiskt synkroniseringsverktyg som används i Microsoft Active Directory miljöer. Det synkroniserar användarkonton, grupper och attribut på schemalagd basis (timme, dag eller vecka). Den stöder inställningar för flera domäner och flera skogar Active Directory och kan synkronisera profilbilder och rumsobjekt.
Guide@@ appen Entra ID (Azure AD): Den här metoden är utformad för organisationer som använder Microsoft Entra ID (Azure AD) och ger automatisk synkronisering i nära realtid av användar konton och attribut direkt från Entra ID till. Det hanteras helt internt och kräver minimal installation.
SCIM 2.0-program: För miljöer utanför Microsoft eller andra identitetsleverantörer som Okta eller Duo möjliggör SCIM-baserade synkroniseringsappar automatisk användarprovisionering och avprovisionering med attributmappning och gruppsynkronisering.
-
Unified CManvändarsynkronisering: Det här alternativet gör det möjligt att skapa användarkonton baserat på befintliga slutanvändare genom att synkronisera från till. Detta kräver att Cloud Connected UC (CCUC) körs på lokala kluster. Det rekommenderas dock generellt att synkronisera användare från en centraliserad molnkatalog som Entra ID snarare än direkt från.
-
API-provisionering: Offentliga API:er (People, SCIM 2.0) kan användas för att tillhandahålla användare. Den största fördelen med att använda API:er är möjligheten att integrera användarprovisionering med andra företagssystem.
Den här översikten och tabellen återspeglar de viktigaste tilldelningsalternativen för användare, deras fördelar och begränsningar för att hjälpa dig att välja den bästa metoden för din organisations behov.Tabell 6. Tillhandahållande av användare för Tilldelningsmetod Beskrivning Fördelar Nackdelar Manuell Skapa/hantera användare individuellt i Enkelt för få användare, ingen infrastruktur behövs Inte skalbar; tidskrävande för många användare Bulk (CSV-fil) Importera/uppdatera användare i bulk via CSV i Effektiv för grupper; ingen kodning krävs Manuell CSV-förberedelse; mindre dynamisk Människor och SCIM 2.0 API Programmatisk användarhantering via Webex API:er Flexibel; stöder automatisering och integration Kräver utveckling och infrastruktur Katalogsynkronisering Automatisk synkronisering från AD, Entra ID, SCIM-appar, Unified CM Automatiserar livscykeln; stöder filtrering och kartläggning Inställningskomplexitet: vissa av alternativen har begränsade funktioner eller kräver infrastruktur
Användargrupper
Användargruppshantering i gör det möjligt för administratörer att organisera användare i grupper för effektiv masshantering av licenser, inställningar, och resurser. Grupper hjälper till att effektivisera administrationen genom att tillämpa principer, licenser och inställningsmallar för flera användare samtidigt, i stället för att hantera användare individuellt.
Hantering av användargrupper erbjuder flera fördelar inklusive:
-
Förenklad administration: Hantera licenser, inställningar och policyer för flera användare samtidigt.
-
Kon sekvens: Tillämpa enhetliga inställningar och licenser för användare i samma grupp.
-
Skalbarhet: Stöder upp till 250 000 medlemmar per grupp.
-
Integrering: Synkronisera grupper från Microsoft Entra ID (Azure AD) eller Active Directory för automatiserad användar- och grupphantering.
-
Flexi bilitet: Skapa lokala grupper eller synkronisera säkerhetsgrupper; hantera grupp medlemskap manuellt eller via CSV-filer.
-
Resursallokering: Kontrollera åtkomst till inbäddade appar och tjänster baserat på gruppmedlemskap.
De viktigaste användningsfallen för användargrupper vid etablering är:
-
Licens tilldelningar: Tilldela licenser till grupper för att automatiskt tillhandahålla tjänster som samtal, möten, meddelanden eller hybridtjänster till gruppmedlemmar.
-
Inställningsmallar: Använd samlingar av tjänsteinställningar (t.ex. meddelanden, möte, samtal) på grupper för enhetlig användarupplevelse.
-
Han@@ tering av massanvändare: Lägg till eller ta bort användare i bulk via CSV-filer eller katalog synkronisering.
-
Automatisering och integration: Använd API:er eller katalogsynkronisering för automatiserad livscykelhantering för användare och grupper.
Följande tabell sammanfattar de olika alternativen för att hantera användargrupper och grupphan tering i.
| Alternativ | Beskrivning | Fördelar | Nackdelar |
|---|---|---|---|
| gruppprovisionering (grupper) | Skapa och hantera grupper direkt i. Lägg till/ta bort medlemmar manuellt eller via CSV. | Full kontroll över gruppmedlemskap Omedelbar tillämpning av licenser och mallar Enkelt att skapa och redigera grupper |
Manuella uppdateringar krävs Risk för fel vid manuella CSV-uppladdningar Ingen automatisk synkronisering med externa kataloger |
| Synkroniserade grupper från Entra ID (Azure AD) eller Active Directory | Synkronisera säkerhetsgrupper och medlemskap automatiskt från externa katalog tjänster. | Automatiserad synkronisering minskar manuellt arbete Säkerställer överensstämmelse med företagskatalogen Stöder stora organisationer |
Det går inte att redigera gruppmedlemskap i Synkroniseringsfördröjning upp till 12 timmar Kapslade grupper kräver manuell markering |
| Grupper och SCIM 2.0 API (grupper) | Använd grupper eller SCIM 2.0 API för programmatisk grupp- och medlemshantering | Automation och integration med andra system Skalbar för stora eller komplexa miljöer |
Kräver utvecklingsinsats Komplexitet beror på API-användning |
Medan synkroniserade grupper säkerställer konsistens och erbjuder en enda administrationspunkt, är en hybridmetod som kombinerar synkroniserade grupper och grupper (antingen hanterade i kontrollhubben eller via API:er) möjlig. Så, till exempel grupper för licenstilldelning kan vara synkroniserade grupper och en separat uppsättning grupper kan användas för att tilldela användar- och samtalsmallar.
Detta omfattande tillvägagångssätt för hantering av användargrupper gör det möjligt för organisationer att effektivt hantera användarlicenser, inställningar, och policyer, vilket säkerställer konsekventa och skalbara samarbetsupplevelser.
Rekommenderat tillvägagångssätt vid migrering från till
Den primära datakällan för användare på är databasen, som innehåller slutanvändarinformation. i alla fall, är vanligtvis inte den auktoritativa källan för hantering av användaridentitet och ännu viktigare kommer att stängas av i slutet av övergången och utesluts därför som långsiktig auktoritativ källa för identitetsinformation.
Cisco rekommenderar att du använder en centraliserad molnkatalog som Microsoft Entra ID (Azure AD) som enda sanningskälla för användaridentiteter. Synkronisera användare från Entra ID för att säkerställa konsistens, förenklar hantering och stöder funktioner för enkel inloggning (SSO).
För att säkerställa att alla användare på också finns i Entra ID bör organisationer kontrollera att användarkontona i motsvarar konton i Entra ID. Detta kan göras genom att exportera användarlistor från och jämföra dem med användarlistor för Entra ID.
Sammanfattningsvis är den rekommenderade etableringsmetoden att synkronisera användare från Microsoft Entra ID (Azure AD) till Webex med hjälp av guiden Azure AD eller SCIM-appar. Manuell och CSV-bulkprovisionering finns som kompletterande metoder, men är mindre skalbar och mer felbenägen för stora organisationer. Att säkerställa att Entra ID är den auktoritativa källan och att alla användare finns i Entra ID är avgörande för en lyckad migrering och konsekvent användar upplevelse över och miljöer.
Övergången från en lokal katalogtjänst, till exempelActive Directory, till en molnkatalogtjänst, som Entra ID (Azure ID), är oberoende av anropsövergången. Cisco rekommenderar att övergången till en molnkatalogtjänst avslutas innan samtalsöver gången påbörjas.
Designa användargrupper
Efter att ha övergått företagskatalogen från lokalt till molnet samlar du in de användargrupper som krävs som drivs av licens- och funktion smallkrav. För varje gruppdokument:
-
Gruppnamn: unikt namn på gruppen.
-
Licenser: licenser som ska tilldelas denna grupp (om sådana finns) och omfattning (bör licenser tilldelas befintliga användare eller endast till nya användare)
-
Inställningsmallar: Webex App- och Användarsamtalsmallar.
-
Katalogsynkronisering: Synkroniseras den här gruppen från företagskatalogen eller är detta en lokal Webex-grupp etablerad i Control Hub eller via ett API.
-
Beskrivning: hur kommer den här gruppen att användas och vilka användare som ska vara medlemmar i den här gruppen
Dessa uppgifter kommer att användas senare under implementeringsfasen för att skapa lokala grupper eller grupper i företagskatalogen och hantera användarnas gruppmedlemskap.
Enkel inloggning (SSO)
Cisco rekommenderar användning av SSO för användarautentisering. Att använda SSO har några övertygande fördelar inklusive:
-
Förenklad användarautentisering: Användare kan logga in en gång med sina företag suppgifter (t.ex. från Azure ID) för att komma åt och andra integrerade program, vilket eliminerar behovet av flera lösenord och minskar inloggningsuppmaningarna. Detta ökar säkerheten genom att säkerställa att företagslösenord aldrig lagras eller överförs till efter autentisering.
-
Förenklad användarhantering: Automatiserar skapande, uppdateringar och in aktivering av användarkonton baserat på ändringar i företagskatalogen, vilket minskar administrativa kostnader och säkerställer att endast behöriga användare har åtkomst.
-
Förbättrad säkerhet: SS O minskar lösenordsutmattning och risken för lösenordsrelaterade överträdelser genom att centralisera autentisering via betrodda identitetsleverantörer (IDP).
-
Enkel integration av multifaktorautentisering (MFA): MFA kan enkelt stödjas antingen genom en Identity Access Management- lösning som Cisco Duo eller genom MF A-stöd för IdP.
Det finns flera alternativ för att implementera SSO för tjänster:
-
SAML 2.0-baserad SSO: Det primära protokollet som stöds för SSO integration, vilket möjliggör säkert utbyte av autentiseringsinformation mellan Id P och tjänsteleverantören.
-
OpenID connect (OIDC): Stöds som ett alternativt modernt autentiseringsprotokoll för SSO-integration.
-
Webex-identitet: Stö ds även som alternativ för identitetsleverantör.
SSO konfigureras och hanteras centralt genom, vilket kräver utbyte av metadata mellan och den valda IdP.
Efter konfigurationen kan SSO testas inom innan aktivering för att säkerställa korrekt installation.
Cisco stöder integration med flera testade och vanliga IDP och IAM (Identi ty Management System), inklusive men inte begränsat till:
-
Cisco Duo
-
Okta
-
Microsoft Active DirectoryFederationstjänster (ADFS)
-
Microsoft Azure
-
Ping Federate
-
OpenAM
-
F5 BIG-IP.
Dessa IDP överensstämmer med SAML 2.0- eller OpenID Connect-standarderna och har validerats för kompatibilitet med Ciscos samarbetslösningar.
Stöd för flera IdP
gör det möjligt för organisationer att konfigurera SSO med flera IDP för att tillgodose komplexa IT- miljöer som fusioner, förvärv eller decentraliserade IT-avdelningar där olika grupper använder olika IDP. Stöd för flera IdP kan antingen implementeras med funktionen Multi ple IdP i eller genom integration av ett företags-IAM-system som Cisco Duo.
Stödet för flera identitetsleverantörer (IdP) hanterar flera viktiga användningsfall där organisationer kräver flexibel och säker autentisering i olika IT-miljöer:
1. Fusioner och förvärv
När företag går samman eller förvärvar andra har de ofta separata IT-infrastrukturer och distinkta IDP som inte kan federera. Stöd för flera IdP gör det möjligt för användare från båda organisationerna att autentisera och samarbeta säkert utan att behöva förena sina identitetssystem omedelbart.
2. Flera oberoende IT-avdelningar
Stora organisationer eller statliga institutioner kan ha flera oberoende IT-avdelningar, var och en hanterar sin egen IdP. Dess flera IdP-funktion gör det möjligt för dessa avdelningar att upprätthålla sina egna autentiserings system samtidigt som användarna kan komma åt sömlöst.
3. Olika användargrupper eller domäner
Organisationer med olika användargrupper (t.ex. anställda kontra entreprenörer) eller flera e-post domäner kan konfigurera routningsregler för att dirigera autentiseringsbegäranden till lämplig IdP baserat på domän- eller gruppmedlemskap. Detta stöder differentierade åtkomstpolicyer och säkerhet skontroller.
4. Stöd för olika autentiseringsprotokoll
stöder IDP för SAML och OpenID Connect (OIDC), vilket gör det möjligt för organisationer att integrera olika typer av identitetsleverantörer enligt deras befintliga infrastruktur och säkerhetskrav.
5. Förbättrad säkerhet och efterlevnad
Genom att aktivera flera IDP kan organisationer implementera starkare autentiseringsmekanismer, inklusive multifaktorautentisering (MFA) genom integrationer som Duo, och genomdriva konsekventa säkerhetspolicyer för olika användarbaser.
6. Förenklad användarupplevelse
Användare kan autentisera med sina befintliga autentiseringsuppgifter från sina respektive IDP, vilket ger en enhetlig inloggningsupplevelse trots den underliggande komplexiteten hos flera identitetssystem.
Stöd för flera IdP ger flexibilitet, men det kräver noggrann samordning mellan säkerhets- och identitetsteam för att upprätthålla konsekventa säkerhetspolicyer och undvika potentiella sårbarheter.
Duo MFA med SSO för
Duo Access Gateway (DAG) kan autentisera användare med befintliga lokala eller molnbaserade kataloger som Active Directory (AD) och OpenLDAP. Det stöder också integration med andra identitetsleverantörer som Microsoft ADFS, Microsoft Azure, Okta, OneLogin, CAS och Shibboleth. Denna flexibilitet gör det möjligt för organisationer att använda sin nuvarande katalog infrastruktur för Webex SSO med Duo MFA.
Duo fungerar som ett starkt autentiseringslager ovanpå den primära katalogautentiseringen. Den fungerar som en identitetsleverantör (IdP) som använder SAML 2.0 för att genomdriva tvåfaktorsautentisering (2FA) innan åtkomst beviljas. Duo utvärderar användar-, enhets- och nätverkskontext mot konfigurerbara policyer för att tillåta eller neka åtkomst, vilket förbättrar säkerheten utöver bara användarnamn och lösenord. Duo tillhandahåller också flexibla policykontroller, som att kräva MFA vid varje inloggning för vissa appar och mindre ofta för andra.
Fördelarna med Cisco Duo inkluderar:
-
Förbättrad säkerhet: Lä gger till phishing-resistent MFA för att skydda åtkomst, vilket minskar risken för komprometterade lösenord.
-
Flexibla policyer: Tillåter detaljerad kontroll över autentiseringskrav per program eller användargrupp.
-
Integration med befintliga kataloger: Stö der lokal AD, OpenLDAP, moln kataloger och olika SSO-leverantörer, vilket minimerar infrastrukturförändringar.
-
Användarvänlighet: Stö der Single Sign-On (SSO) för att minska lösenordsutmattning genom att göra det möjligt för användare att logga in en gång och få tillgång till flera resurser på ett säkert sätt.
-
Betrodda slutpunkter: Stöder enhetsförtroende för klienter på Windows och macOS, vilket förbättrar säkerhetsställningen.
-
Självbetjäningsregistrering: Inbyggd registrering och duo-prompt förbättrar användarupplevelsen under MFA-installationen.
Duo MFA med SSO för utnyttjar befintliga kataloger som Active Directory och OpenLDAP, eller molnidentitet sleverantörer, för att autentisera användare. Duos roll är att tillhandahålla en stark, policydriven andra autentiserings faktor integrerad genom SAML 2.0, vilket förbättrar säkerheten samtidigt som användarvänligheten upprätthålls genom SSO. Fördelarna inkluderar förbättrad säkerhetsställning, flexibel policy tillämpning, sömlös integration och en bättre användarupplevelse.
Cisco rekommenderar att implementera SSO för användare. För förbättrad säkerhet rekommenderas integrering med Cisco Duo.
Enterprise IAM- och SSO-strategin bör implementeras innan övergången från till påbörjas.
Funktioner
har ett komplett komplement av kärnfunktioner som ingår i tjänsten. Detta inkluderar många samtalsfunktioner i företagsklass som har funnits i många år. Du kanske inte ser 100% paritet mellan funktioner och funktioner, men som du kan se i figuren nedan är de viktigaste samtalsfunktionerna tillgängliga i.
Förutom de många användarfunktionerna, har kärnsystemfunktioner som ingår i plattformen. Dessa inkluderar funktioner som automatiska skötare, samtalsköer, samtalspark, etc. Du kan se alla tillgängliga kärnsystem funktioner under Service → Ring →Funktioner som visas i figur Webex Callingkärn funktioner.
Automatisk skötare
Auto Attendant möjliggör 24/7 automatisering av hantering av inkommande samtal, vilket möjliggör effektiv samtalshantering utan att en person behöver svara på varje samtal.
Den automatiska mottagaren svarar på inkommande samtal och ger den som ringer en meny med alternativ för vart de vill dirigera sitt samtal. Detta kan vara till en person, en röstbrevlåda eller en samtalstjänst (t.ex. Samtalskö). Den som ringer använder telefonens knappsats för att ange numret från menyn för automatisk sköt sel.
Auto Attendant stöder följande nyckelfunktioner:
-
Affärs- och eftertidscheman
-
Semesterschema
-
Alternativet för uppringningsmeny för att rikta dina kunder dit de behöver gå
-
Anpassa hälsningar
-
Alternativ för att ringa efter namn
-
Alternativ för vidarekoppling av samtal
-
Control Hub-analys och rapporter.
Mer information finns i Hantera automatiska telefonsvar are.
Ring Park
Call park ger användarna möjlighet att enkelt sätta ett samtal i väntelä ge så att en annan användare enkelt kan hämta när de är tillgängliga för att ta det. Det frigör också användaren som svarade på det ursprungliga samtalet för att ringa eller ta emot andra samtal medan samtalet är parkerat.
Det finns två typer av samtalsparker tillgängliga i:
-
Call park direct - gör det möjligt för alla användare att parkera ett samtal till en annan användares anslutning eller till en samtalspark-förlängning, enligt definitionen av administratören
-
Samtalsparkgrupp - gör det möjligt för en definierad grupp användare att automatiskt parkera samtal mot tillgängliga parkeringsdestinationer som definierats för gruppen. Dessa destinationer kan vara gruppmedlemmarnas tillägg eller samtalsparktillägg.
Baserat på konfiguration och parker ingstyp kan användare hämta samtal genom att <extension of parked call>ringa *88+>, trycka på linjeknappen som är kopplad till samtalspar kens förlängning eller använda en funktionsknapp på sin IP-telefon.
Ett återkallningsalternativ är tillgängligt för att återkalla ett parkerat samtal efter en viss period till användaren som parkerade samtalet eller till en alternativ användare.
Mer information finns i Hantera samtalsparkering i Control Hub.
Upphämtning av samtal
Samtalsupptagning gör det möjligt för en administratör att definiera en grupp användare (medlemmar) som kan svara på ett samtal till en annan medlems telefon. Detta ger en användare möjlighet att svara på samtal när deras lagkamrater är upptagna och inte kan svara på ett inkommande samtal.
Användarna i en grupp måste vara på samma plats.
Användare kan använda antingen skrivbordstelefonen eller deras skrivbordstelefon för att hämta ett samtal.
-
:
-
Stöder visuella och ljudmeddelanden
-
Meddelande om inkommande samtal
-
FAC-baserad (ring *98) eller avisering av samtalsupphämtning
-
Meddelanden om upphämtning av samtal för multiline.
-
-
Skrivbordstelefoner:
-
Meddelande om inkommande samtal
-
Ljudklockor och visuell avisering via handenhetens LED. 6821 stöder endast ljudklockor
-
När meddelandetypen är vald i är inte ingen
-
-
Meddelanden om upphämtning av samtal endast för primära linjer.
-
Mer information finns i Konfigurera samtalsupphämtnings grupp.
Samtalskö
inkluderar röstsamtalsköer som en del av sina kärnfunktioner och alla användare med en Professional-licens kan vara en del av en samtalskö, agent eller handledare. Denna funktion gör det möjligt för användare att effektivt interagera med kunder. Samtalsköer stöder en delmängd av några av callcen ter-kärnfunktionerna som röstköer, återuppringning, skicklighet eller prioritetsdirigering, hantering av agentköer, analys, rapportering, etc.
Ciscos call for Microsoft Teams-integration gör det möjligt för agenter att komma åt samtalskösamtal och funktioner direkt från sin Microsoft Teams-klient.
Samtalsköer stöder följande nyckelfunktioner:
-
Hälsningar och meddelanden (välkommen, tröst, viskning, etc)
-
Håll musik
-
Återuppringning
-
Policyer för köruttning (nattservice, helgdagar, vidarebefordran)
-
Inloggning/utloggning av agentkö
-
Hantering av agentköstatus
-
eller Desk Telefonsupport
-
Handledare anropar, tränar, pråmar eller tar över genom Feature Access Codes (FACs)
-
(administratörsåtkomst) för:
-
köhantering
-
Agent- och köanalys och rapportering
-
Kö-, agent- och handledarhantering.
-
Mer information finns i Konfigurera samtalsk ö.
har en tilläggsfunktion för kundassistans som ger ytterligare samtalsköfunktioner och ger agenter och handledare en bättre användarupplevelse inom. För en jämförelse av funktionerna Samtalskö och Kundassistans, se Jämfö Webex Callingrelse av samtalskö och kundassistans funktioner.
Jaktgrupp
Hunt Groups möjliggör dirigering av inkommande samtal till en specifik grupp av användare genom ett förutbestämt samtalsrutningsmönster. Detta säkerställer att samtal besvaras av rätt grupp användare eller skickas till en röstbrevlåda för uppföljning.
En stor skillnad mellan jaktgrupper och samtalsköer är att samtal inte köas i en jaktgrupp, så om inga användare i Hunt Group är tillgängliga för att svara på samtalet kommer det att kopplas bort, skickas till röstbrevlådan eller vidarebefordras till ett annat nummer (användare eller tjänst).
Mer information finns i Hantera jaktgrupper i Control Hub.
Driftlägen
Funktionen Operating Modes gör det möjligt för företag att effektivt dirigera samtal till olika destinationer (användare, röstbrevlåda, samtalstjänster som en samtalskö). Var och när ett samtal dirigeras är baserat på ett schema för tid på dagen och veckodag och alla användare kan behörighet att hantera dessa lägen (scheman) för att styra ändringar i samtalsdirigeringen.
Som ett exempel kan samtal till en samtalskö dirigeras till en annan samtalskö med agenter i en annan tidszon för att svara på samtal efter öppettider, under kontorstid dirigeras till lokala agenter, och under helgdagar dirigeras till röstbrevlådan för upp följning efter att agenter återvänt till kontoret.
En auktoriserad användare kan växla mellan dessa olika vidarekopplingsscenarier (lägen) om de behöver ändra var inkommande samtal dirigeras under en viss period. Dessa användare kan hantera lägena via sina 6800/7800/8800 MPP-telefoner, 9800-telefoner eller i användarnavet i Hantera lägen.
Mer information finns i Samtal sdirigering baserat på driftlägen i Webex Calling.
Personsökningsgrupp
Personsökningsgrupper tillåter användare att ringa ett enkelriktat samtal för att skicka ett ljudmeddelande till en grupp användare. Varje grupp kan innehålla upp till 75 målanvändare och/eller arbetsytor som nås genom att ringa ett fördefini erat nummer eller anknytning.
När en användare anropar en personsökningsgrupp görs ett samtidigt samtal till alla tilldelade mål i gruppen, vid vilken tidpunkt den som ringer kan tala sina meddelanden och lägga på när de är färdiga.
Mer information finns i Konfigurera en personsökningsgrupp i Control Hub.
Inspelningar
stöder inspelning av samtal som gjorts eller tagits emot av en användare. Detta kan krävas för kvalitets-, säkerhets-, säkerhets- eller utbildningsbehov. Som standard spelas samtal in, men andra tredjepartsinspelningsleverantörer kan också användas om andra inspel ningsfunktioner eller efterlevnad och lagkrav krävs.
När du använder som inspelningsplattform hanteras alla inspelade samtal inom. Fullständiga administratörer med rollen Compliance officer kan spela och ladda ner inspelningarna. Utan rollen Compliance officer kan administratören bara ta bort inspelningarna.
Mer information om den här funktionen och en lista över inspelningar från tredje part finns i Hantera samtalsin spelning för Webex Calling.
Räckvidd för enstaka nummer
Räckvidd med ett enda nummer tillåter samtal till en användares telefonnummer för att ringa flera enheter. Detta kan inkludera andra skrivbordstelefoner såväl som mobiltelefoner. Samtal kan också göras från dessa enheter och användare kan trycka och dra samtal mellan dem.
Mer information om den här funktionen och hur en administratör konfigurerar den i finns i Konfigurera enstaka nummerräckvidd (kontor var som helst).
Mer information om hur en användare kan hantera och konfigurera den här funktionen för sig själv i Webex User Hub (portalen) finns i Konfigurera enstaka nummer räckvidd (kontor var som helst).
Röstbrevlådegrupp
Röstbrevlådegrupper tillåter en delad röstbrevlåda som kan tilldelas en användare eller samtalsroutningsfunktion. Några av anledningarna till att en röstbrevlådegrupp kan krävas är:
-
Allmän röstbrevlåda för en avdelning eller arbetsgrupp
-
Lägg till röstbrevlådealternativ till en automatisk skötare eller jaktgrupp
-
Så här skickar du överströmningssamtal från en samtalskö
-
Användare som bara behöver en röstbrevlåda.
Mer information finns i Hantera en delad röstbrevlåda och inkommande fax box för. Webex Calling
Attendant Console visas på sidan Samtalsfunktioner i Webex, men det är en tilläggsfunktion som kräver köp av den medföljande konsol licensen för att använda.
Mer information finns i Komma igång med Attendant Console.
Information om alla funktioner, inklusive vissa tilläggsfunktioner, finns i Funktioner tillgängliga efter licenstyp för Webex Calling.
Implementera
Nätverksberedskap
Det första steget i övergången till är att säkerställa tillförlitlig och säker internetanslutning mellan det lokala nätverket och molnet.
Eftersom de flesta organisationer ansluter till internet via en eller flera brandväggar eller säkerhetsenheter är det viktigt att validera att de nödvändiga trafikflödena stöds.
Nätverks- och säkerhetsadministratörer måste förstå dessa flöden i termer av:
-
Riktning (inkommande vs utgående)
-
Protokol l (Exempel - SIP TLS, SRTP, HTTPS)
-
IP-adressintervall som används av tjänster
-
Portnummer som måste öppnas eller tillåtas.
Detta säkerställer att företagets brandväggar, NAT-enheter och annan nätverksinfrastruktur är korrekt konfigurerade för att tillgodose trafik samtidigt som företagets säkerhetsprinciper upprätthålls.
För information om nödvändiga flöden inklusive IP-adress, portar, och protokoll, se Portreferensinformation för Webex Calling. Använd den här informationen för att konfigurera brandväggen, proxyer och annan nätverksinfrastruktur i den befintliga distributionen för att aktivera nätverksflöden.
Decentraliserat internetutbrott från varje filial eller webbplats är det rekommenderade tillvägagångssättet för molnsamarbetstjänster som t.ex. Genom att tillåta trafik att avsluta lokalt, denna modell:
-
Minskar returfördröjning och jitter, vilket förbättrar den totala samtalskvaliteten
-
Skalas effektivt när fler användare och webbplatser övergår till
-
Fungerar sömlöst med SD-WAN, som dynamiskt kan dirigera sessioner till närmaste molningångspunkt för optimal prestanda
- Gör det möjligt att spåra användarens plats baserat på deras offentliga IP-adress vilket hjälper till med analys av medievägar och felsökning.
Dessutom måste organisationer säkerställa tillräcklig internetbandbredd på varje webbplats. Bandbredden bör dimensioneras baserat på det förväntade antalet samtidiga samtal, den valda codec (t.ex. Opus eller G.711), plus overhead för signalering, återsändningar och tillväxt. Detta överensstämmer med förberedelse fasen i PPDIO-livscykeln och skapar en solid grund för migrering.
Inledande installation
Det första installationsunderavsnittet inom implementeringsfasen för distribution är grundläggande för att skapa en välstrukturerad och hanterbar molnsamtalsmiljö. Detta steg omfattar viktiga uppgifter som att konfigurera organisationen, anskaffa och tilldela licenser och verifiera och göra anspråk på företagets domäner för att säkerställa korrekt användarhantering och säkerhet. Dessutom innehåller den provision eringslicensmallar för att automatisera tilldelningar av användarlicenser, konfigurera Single Sign-On (SSO) för att effektivisera användarautentisering och förbättra säkerheten samt justera service- och klientinställningar så att de överensstämmer med organisationens principer och användarbehov. Genom att slutföra dessa initiala installation saktiviteter säkerställs att miljön är korrekt konfigurerad för skalbarhet, säkerhet och sömlös användarupplevelse, vilket skapar förutsättningar för efterföljande driftsättning och driftsfaser.
Domänverifiering
För att kunna identifiera användare som är registrerade med ditt företags e-postdomäner är det viktigt att verifiera dina domäner. Utan domänverifiering kommer användare att tilldelas en konsumentorganisation, vilket komplicerar användarhanteringen för ditt företag. Domänverifiering är ett obligatoriskt steg som gör det möjligt för din organisation att göra anspråk på och hantera dessa användare effektivt.
Se till att alla domäner som är kopplade till dina användares e-postadresser verifieras. Dom änverifiering är inte exklusiv; samma domän kan verifieras i flera organisationer.
Mer information om hur du hanterar domäner finns i Hantera dina domäner.
Gör anspråk på (konvertera) befintliga användare
När du har verifierat dina domäner kan du fortsätta att göra anspråk på användare som har registrerat sig för att använda företagets e-postdomäner i din organisation. Denna process konsoliderar alla användare under ett enda organisatoriskt paraply, vilket möjliggör centraliserad hantering och strömlinjeformad administration. Genom att göra anspråk på dessa användare säkerställer du att ditt företag har full kontroll över användarkonton, så att du kan tilldela lämpliga licenser, konfigurera tjänster och tillhandahålla nödvändig support effektivt. Denna enhet liga hanteringsstrategi förbättrar säkerheten, förenklar användarprovisionering och säkerställer konsekvent åtkomst till tjänster i hela organisationen. Att hävda användare hindrar dem också från att hanteras i externa organisationer eller konsumentorganisationer, vilket upprätthåller organisationens integritet och kontroll över samarbetsresurser.
Mer information om hur du gör anspråk på användare finns i Gör anspråk på användare till din organisation (konvertera) användare.
Konfigurera och testa katalogsynkronisering
Om du vill aktivera sömlös användar- och grupphantering kan du synkronisera användare och grupper från företagskatalogen antingen Microsoft Entra ID (tidigare Azure AD) eller Microsoft Active Directory (AD) till. Denna process säkerställer att användaridentiteter och gruppmedlemskap upprätthålls konsekvent i hela din miljö.
För organisationer som implementerar stegvisa distributioner är det viktigt att kontrollera och begränsa omfattningen av synkronisering under de första utrullningarna. Detta minimerar risken för oavsiktliga förändringar och möjliggör riktad testning före bredare antagande.
Den mest effektiva metoden för att filtrera vilka användare som synkroniseras är att utnyttja kataloggruppsmedlemskap:
| 1 |
Skapa en dedikerad synkroniseringsgrupp: I din företagskatalog (Microsoft Entra ID eller AD) skapar du en säkerhetsgrupp specifikt för synkronisering (till exempel synkroniseringsgrupp). |
| 2 |
Fyll i gruppen med målanvändare: Lägg bara till de användare som du vill synkronisera (till exempel en testgrupp under pilotfasen) till den här gruppen. Detta gör att du kan kontrollera vem som ingår i synkroniseringsprocessen. |
| 3 |
Konfigurera synkroniseringsavtalet med gruppbaserad filtrering: När du konfigurerar synkroniseringsavtalet i Directory Connector eller Entra ID-provisionering konfigurerar du omfattningen så att den endast omfattar användare som är medlemmar i den angivna gruppen.
|
| 4 |
Expandera gruppen efter behov: När du går vidare till bredare distributionsfaser lägger du helt enkelt till ytterligare användare eller grupper i synkroniseringsgruppen. Synkroniseringsomfång et utvidgas automatiskt till att omfatta dessa användare, vilket möjliggör kontrollerad och gradvis utrullning. Exempel på implementeringssteg:
Referenser: Synkronisera användare av Entra ID till Control Hub |
Konfigurera och testa Single Sign-On (SSO)
Single Sign-On (SSO) förbättrar säkerheten och förenklar användaråtkomst genom att låta användare autentisera en gång med sina företagsuppgifter och få sömlös åtkomst till. stöder SSO-integration med SAML 2.0-kompatibla IDP:er, inklusive Microsoft Entra ID (tidigare Azure AD), Active Directory (AD) federerade lösningar och olika tredjeparts-IDP.
Vid denna tidpunkt bör den designade SSO-installationen implementeras och testas.
Referenser:
Integrering av enkel inloggning i kontrollhubben
konfigurera enkel inloggning för webex-administration
Anskaffa, tillhandahålla och verifiera licenser
Som en del av den första installationen för är det viktigt att anskaffa, tillhandahålla och verifiera lämpliga licenser för att aktivera och hantera tjänster effektivt. Upphandlingsprocessen innebär att du väljer licen styper baserat på användarroller och arbetsbelastningar, till exempel Professional-, Standard- och Workspace- licenser. Licenser genereras och tillhandahålls via Ciscos mjukvaruplattformar eller genom partners. Efter upphandling och tillhandahållande måste korrekta licensantal verifieras i. Denna process säkerställer att organisationen har rätt licenser aktiverade och redo att användas i distributionen.
Som en del av den första licensinställningen i är det viktigt att konfigurera organisationsbaserad automatisk licensiering för att effektivisera tilldelningen av licenser för nya användare. Med den här inställningen kan licenser beviljas automatiskt när användare läggs till i organisationen, vilket eliminerar behovet av manuell licenstill delning. När du konfigurerar automatisk licensiering på organisationsnivå väljer du de tjänster som ska tilldelas och definierar omfattningen, till exempel att endast tillämpa licenser på framtida användare eller inkludera befintliga användare.
Om distributionsplanen innebär att du använder automatisk licensiering på gruppnivå i stället kan du välja att inte tilldela licenser på organisationsnivå för att undvika konflikter eller dubbla licenstilldelningar. Med automatisk licensiering på gruppnivå tilldelas licenser baserat på gruppmedlemskap. Användare i flera grupper får licenser från alla tillämpliga grupptilldelningar.
Gruppbaserad licenstilldelningskonfiguration måste utföras efter att katalogsynkroniseringen har slutförts så att synkroniserade grupper finns och kan användas för tilldelning av licenser.
I synnerhet kräver automatisk tilldelning av licenser ytterligare information om etablering, till exempel användarplats och tilldelning av telefonnummer. Användarens arbetstelefonnummer måste vara i +E.164-format, förinstallerat och tilldelat en giltig plats för att licensen ska aktiveras automatiskt. Om dessa villkor inte uppfylls kommer användaren inte att tillhandahållas tjänster automatiskt och kan kräva manuell ingripande.
Sammanfattningsvis konfigurerar du organisationsbaserad automatisk licensiering för nya användare om du vill ha en bred, organisationsomfattande licenstilldelning. Om du föredrar mer detaljerad kontroll eller har olika licensbehov per grupp konfigurerar du automatisk licensiering på gruppnivå och undviker tilldelning av licenser på organisationsnivå för att förhindra överlappning och säkerställa korrekt licenshantering.
Webex Calling Serviceinställningar
Det är viktigt att genomföra en omfattande granskning och konfiguration av de globala service inställningarna inom.
Börja med att komma åt och navigera till inställningsavsnittet. Undersök noggrant varje konfigurerbart alternativ, inklusive, men inte begränsat till, intern uppringningskonfiguration, nödsamtalsparametrar, samtalsrutningspolic yer, röstbrevlådehantering och enhetens standardinställningar.
Justera de globala inställningarna så att de återspeglar organisationens policyer och designbeslut.
Också, inställningsinställningar och användar- och appmallar.
Pilotmigrering
Under implementeringsfasen, genomförandet av en pilotmigration representerar en kritisk milstolpe för att validera övergången från till. Detta pilotprojekt innebär att en representativ delmängd av användare etableras på en eller flera platser på plattformen, vilket säkerställer att den valda populationen återspeglar olika användningsfall och organisatoriska roller. Parallellt med användarmigrering måste viktiga samarbetstjänster inklusive röstbrevlåda, automatiska sköer, samtalsköer och jaktgrupper övergå till sina motsvarigheter för att upprätthålla affärskontinuitet och tjänstefunktionalitet.
Pilotmigreringen bör utnyttja samma kombination av Cisco-tillhandahållna verktyg och migreringsverktyg från tredje part som planeras för den bredare organisatoriska distributionen, vilket säkerställer att processer, automatiseringsarbetsflöden och integrationspunkter valideras noggrant under representativa förhållanden.
De primära målen för denna pilotdistribution är tvåfaldiga: för det första, att validera och förfina övergångsprocesserna från början till slut inklusive arbetsflö den för användarprovisionering, datami greringsprocedurer, och slutpunktskonfigurationer; och för det andra, att fullständigt verifiera funktionaliteten hos migrerade tjänster under verkliga operativa förhållanden.
Detta stegvisa tillvägagångssätt gör det möjligt för projektgruppen att identifiera och åtgärda eventuella tekniska eller procedurmässiga problem i en kontrollerad miljö, samla in feedback från användare om den nya plattformsupplevelsen, bedöma effektiviteten hos utvalda migr eringsverktyg och skapa förtroende för migreringsm etoderna innan de fortsätter med en bredare organisatorisk distribution.
De insikter som erhållits under denna pilotfas är avgörande för att optimera efterföljande migrationsvågor och säkerställa en smidig, riskreducerad övergång för hela företaget.
Skaffa PSTN
För att anskaffa PSTN-tjänster för, välj först ett PSTN-anslutningsalternativ i.
Om en organisation planerar att upprätthålla hybrid dubbel samtalskontroll (fas 1 i figur Fasad samtalsövergång: Hybrid och mol n) antingen tillfälligt eller på obestämd tid, måste de distribuera en eller flera lokala gateways för lokalt PSTN för att tillåta samtal mellan och slutpunkter.
Om en fullständig övergång (fas 2) till molnet är slutmålet inklusive PSTN, krävs antingen en Cisco-samtalsplan eller ett Cloud Connect for alternativ för PSTN.
Arbeta med din valda leverantör för att beställa och portera telefonnummer innan du konfigurerar dem. Beställning av telefonnummer eller initiering av portbeställningar krävs/möjligt endast för lokal PSTN och Cloud Connect för. För Ciscos samtalsplaner initieras beställning och portering inifrån Control Hub så snart platsen har skapats och i länder där Cisco Calling Plan är tillgängligt. Mer information om Cisco-samtalsplaner finns i Kom ma igång med C isco-abonnemang.
Som en del av PSTN-implementeringen, se till att din leverantör har aktiverat både inkommande och utgående PSTN-tjänster för din plats. Utför dessutom testsamtal för att verifiera att samtal dirigeras korrekt via din valda PSTN-anslutning.
Konfigurera platser
Innan du lägger till användare och enheter i måste du tillhandahålla samtalsplatser. För varje plats måste en giltig gatuadress anges. I USA och Kanada valideras denna adress och används av plattformen för att skicka PIDF-LO-platsinformation för nödsamtal.
När du konfigurerar platser som använder lokal PSTN måste du konfigurera de lokala gatewayerna i enlighet med detta. I måste en trunk och en ruttgrupp skapas för varje lokal gateway, och rutt gruppen tilldelas sedan som PSTN-val för platsen. Cisco rekommenderar starkt att du alltid väljer en ruttgrupp som PSTN-val, eftersom detta tillvägagångssätt gör att du enkelt kan lägga till ytterligare trunkar i framtiden, vilket stöder både skalbarhet och redundans. Cisco rekommenderar också att du aktiverar stöd för dubbel identitet och P-Charge-Info på varje PSTN-trunk, eftersom detta förenklar identifieringen av den fakturerbara parten för utgående direkta eller omdirigerade samtal. Om din PSTN-leverantör använder en annan rubrik för fakturering kan du kopiera informationen från P-Charge-Info-rubri ken på den lokala gatewayen till den obligatoriska faktureringsrubriken.
För platser som använder Cloud Connect för eller Cisco Calling Plan som sitt PSTN-alternativ, välj helt enkelt respektive PSTN- val för platsen under installationen. Om platsen använder antingen Cloud Connect för eller lokalt PSTN måste du lägga till de telefonnummer som beställdes i föregående steg. Nummer kan läggas till som inaktiva om du inte vill att de ska inkluderas i samtals dirigering direkt; du kan aktivera dessa nummer senare när de tilldelas användare eller funktioner.
Det är viktigt att alltid ställa in huvudnumret för varje plats. Huvudnumret kan tilldelas antingen en användare eller en funktion, till exempel en automatisk skötare. För att aktivera röstbrevlådan på platsen, se till att ställa in röst brevlådans pilotnummer, även känt som röstportalnumret.
Ytterligare inställningar för samtalsplatser inkluderar konfigurering av nödsamtalsinformation som nödsamtalsnummer, meddelande alternativ och förbättrade nödsamtalsfunktioner. Du bör också granska och justera inspelningsinställningar, språkinställningar och enhetskon figurationer efter behov för varje plats. Om din organisation använder förkortad internetuppringning mellan platser med betydande företags nummer, kom ihåg att konfigurera en unik platskod för platsen i de interna uppringningsinställ ningarna. Slutligen, om extern uppringning kräver en siffra för utgående uppringning, se till att ställa in detta i inställningarna för extern uppr ingning. När en utgående uppringningssiffra är konfigurerad rekommenderar Cisco att du aktiverar utgående uppringningssifferverkning för att säkerställa enhetlighet.
Integration med lokal samtalskontroll
För att integrera med lokal samtalskontroll är det nödvändigt att konfigurera trunkar, ruttgrupper, företagsuppringningsplaner och både platsinställningar och globala inställningar. Börja med att ställa in trunkar och lokala gateways avsedda för sammankoppling med det lokala samtalskontrollsystemet. Detta steg krävs endast om dedikerade trunkar är nödvändiga. Om befintliga trunkar och ruttgrupper är tillräckliga för distributionen kan de återanvändas för den lokala sammankopplingen utan ytterligare konfiguration.
När stammarna och ruttgrupperna har upprättats fortsätter du med att skapa företagets uppringningsplaner och tilldela lämplig ruttgrupp som destination för varje uppringningsplan. När integrationen involverar flera lokala samtalskontrollsystem som är anslutna via olika trunkar krävs flera uppringningsplaner. Det är viktigt att se till att uppr ingningsplanerna endast innehåller de mönster som krävs för att dirigera samtal till lokala destinationer.
Om distributionen kräver stöd för okänd tilläggsrouting bör den här funktionen vara aktiverad på platsnivå. Dessutom, när routning av okänd anslutning är aktiverad, måste du ange den maximala okända förlängningslängden i avsnittet Samtalsdirigering mellan och lokaler i inställningarna för samtalstjänster i. Detta säkerställer sömlös samtalsdirigering och korrekt hantering av tilläggsbaserade uppringnings scenarier i din integrerade miljö.
Migrera användare i grupper
När du migrerar användare från till kan du kanske inte flytta alla användare samtidigt. Detta kan bero på flera orsaker, inklusive men inte begränsat till antalet webbplatser eller användare, hur lång tid det tar att överföra en webbplats och/eller grupp användare samtidigt, begränsad IT- eller webbplatsresurs för att stödja ändringsfönstret, varaktighet för ändringsfönstret, förändringens komplexitet etc.
När du migrerar användare i faser är det viktigt att identifiera vilka användare som behöver migrera tillsammans i samma batch. Det primära målet är att migrera användare tillsammans som har beroenden med varandra för sina samtalstjänster och funktioner. Du vill se till att alla deras samtalsfunktioner (Exempel - Samtalsköer) fungerar fullt ut som de var innan övergången aktiverades.
Även om du implementerar samtalssamarbete mellan och med lokala gateways kan du inte dela delade tjänster eller funktioner över den här anslutningen. Därför måste du identifiera beroenden mellan användare genom att titta på funktioner som:
-
Övervaka andra användare som använder BLF:er
-
I samma jaktpilot, samtalskö, etc
-
Delade linjer
-
Använda uppringningsupptagning
-
Använda samma call-park-nummer
-
Intercom
-
Verkställande direktör/administratör.
Ett exempel skulle vara en användare som ingår i en Hunt Group som övergår till. Denna användare kommer att övergå till med Hunt Group och med alla andra medlemmar i Hunt Group. Därför kan Hunt Group och dess medlemmar framgångsrikt svara på samtal på den nya plattformen efter övergången.
Detta blir mer utmanande när användare är anslutna till olika grupper av användare för olika samtalstjänster och funktioner. Detta kräver att mer än en grupp användare och en samtalstjänst övergår till samtidigt.
Använd utdata från verktyget Migration Insights eller tredjepartsverktyg som du använde i förberedelsefasen för att avgöra vilka användare och funktioner som ska grupperas tillsammans. Denna utdata borde ha använts för att utveckla din migreringsplan och ger dig insikter om hur du grupperar användare och funktioner som behöver övergå tillsammans.
De viktigaste stegen när du övergår en grupp användare är:
-
Identifiera användare att migrera tillsammans
-
Kontrollera att alla användare är inne
-
Kontrollera att alla TN för användarna finns i
-
Kontrollera korrekt telefonnummerformat i katalogen
-
Kontrollera att licensierings- och inställningsmallen för användargrupperna är korrekt inställd
-
Verifiera eller konfigurera alla samtalstjänster och funktioner för användar gruppen (före eller under övergången beroende på vad som är lämpligt)
-
Lägg till användare i gruppen av samtalsaktiverade användare i företagskatalog en
-
Utnyttja verktyg - verktyg för migrering av användare och funktioner och/eller verktyg från tredje part
-
Inaktivera/ta bort användare/enhetskatalognummer och samtalsfunktioner/tjänster på efter övergången.
Efter migrering av en grupp användare testar du en delmängd av användarna för att kontrollera att alla deras samtalsfunktioner och tjänster fungerar korrekt. Om samtalsfunktioner som samtalskö, jaktgrupper etc. överförs med gruppen användare, testa sedan dessa samtalstjänster för korrekt funktionalitet.
Arbetsytor
I hänvisar en arbetsyta till en delad plats (som ett konferensrum, mötesutrymme eller ett funktionellt skrivbord) som kan tilldelas enheter, tillägg och användare. Till skillnad från traditionella Unifed CM- telefoner är arbetsytor:
-
Platscentrerad: knuten till fysiska utrymmen.
-
Enhetsflexibel: kan ha en eller flera enheter (skrivbordstelefoner, kort etc.).
När arbetsytor har identifierats som en del av övergången till kan de läggas till under Enheter. Varje arbetsyta behöver en enhetstilldelning, och om de redan Unified CM finns i måste de återställas eller etableras om. funktioner som röstbrevlåda, vidarekoppling och upphämtning av samtal kan aktiveras eller inaktiveras, och policyer kan tillämpas för videosamtal, samtalsparkering och rörlighet efter behov. Testa varje arbetsyta genom att ringa interna och externa samtal, testa video-, konferens- och mobil itetsfunktioner. Slutligen, låt användarna veta om alla tillämpliga processer för arbetsyteenheter och bokningar.
Försörjningsenheter
Telefoner som för närvarande är registrerade på måste migreras till som en del av molnövergången. För att göra migreringen så enkel som möjligt med minimal risk för misslyckande rekommenderar Cisco att migrera fysiska webbplatser eller avdelningar samtidigt. Du kan dock behöva migrera användare i grupper på grund av funktionsberoenden. Se avsnittet Migrera användare i grupper för mer information.
Alla telefoner som stöds som du behöver övergå från måste konfigureras som användare eller arbetsyta och den fysiska telefonen måste konfigureras om för att registrera dig med . Dessutom behöver telefonerna i 7800- och 8800-serien sin firmware uppgraderad från Enterprise- firmware till Multiplatform Phone (MPP) firmware. Denna process inkluderar laddning av övergångs firmware innan du laddar den MPP-firmware som krävs för registrering. Det kräver också lämplig migrationslicens. Cisco har förbättrat denna process under de senaste åren för att göra det lättare för dig att uppgradera dina Enterprise-firmware- telefoner till MPP-firmware. Mer information om stegen för att slutföra uppgraderingen av den inbyggda programvaran finns i Konvertera Cisco 7800- och 8800-seriens IP-telefoner mellan Enterprise- och MP P-firmware.
Förutom stegen som beskrivs i den här artikeln finns det ett inbyggt verktyg, Migrera telefonen till Webex Calling, som du kan använda för att hjälpa till att migrera dina 7800- och 8800-telefoner från Enterprise till MPP-firmware. Med det här verktyget kan du också lägga till telefonerna och tilldela dem till lämpliga användare eller arbetsytor. Mer information om verktygsanvändning finns i Migrera telefonen.
För telefoner i 9800-serien som är registrerade med ovanstående krav på migrering av firmware gäller inte. Dessa telefoner kör PhoneOS, som stöds av både och. För att överföra dessa telefoner till måste du lägga till demWebex Calling, tilldela dem till en användare eller arbetsyta och sedan fabriksåterställa telefonerna. PhoneOS startsekvens för registrering Figur nedan visar PhoneOS-startsekvensen och hur telefonen kommer att registrera sig när den har lagts till, även om telefonen fortfarande är etablerad och/eller DHCP-alternativ (Exempel - 150) används.
stöder fabriksåterställning av PhoneOS-enheter för att möjliggöra Zero-Touch-onboarding till. administratörer kan fjärråterställa 9800- och 8875-telefonerna via CUCM-administrations sidorna, vilket eliminerar behovet av fysisk åtkomst till telefonerna för att ombordlägga telefonerna till. Den här funktionen stöds med enhetspaketen från 9 september 2025:
-
CUCM v15 - Unified Communications Manager version 15
-
CUCM v14 - Unified Communications Manager version 14.
För mer information om registreringsprocessen för 9800-serien, se Registrerings process.
Förutom Ciscos IP-telefoner kan det krävas tillhandahållande av andra enheter som analoga telefon adaptrar (ATA), trådlösa (Wifi, DECT) telefoner, videoenheter, röstgateways och tredje part senheter och telefoner. Många av dessa enheter har ingen uppgraderingsväg för firmware som IP-telefonerna för att överföra dem från företags firmware till moln programvara. Därför kommer du att tillhandahålla var och en av dessa enheter i Control Hub. Vissa av dessa kan inte övergå till och motsvarande modell kommer att behöva ersätta den (t.ex. ATA 191/192) och andra kommer att kräva manuell omkonfiguration och/eller programändringar.
- Röstgateways — Om du vill migrera den lokala gatewayen finns i Mi grera lokal gateway.
-
Analog telefonadapter (ATA) - För att komma igång med Cisco ATA 191 och 192, se Cisco ATA.
-
Trådlös Wifi-telefon - För att integrera trådlös telefon 840 och 860, se Integrera trådlös Webex-telefon.
-
Trådlösa DECT-telefoner - För att komma igång med din nya Cisco IP DECT 6800-serie, se Cisco IP DECT.
Information om hur du bygger och hanterar digitalt DECT-nätverk i Control Hub finns i Hantera DEC T-nätverk
Mer information om Cisco IP DECT 6800 finns i Installationsguide
-
Tred je partsenheter och telefoner - Arbeta med tredje part sleverantörer om enhets-/telefonkrav och processen för att migrera eller ersätta dem för att stödja.
Konfigurera funktioner
Alla samtalsfunktioner som krävs måste etableras före eller under övergången. Som diskuterats under avsnittet Migrera användare i grupper måste anropsfunktionerna konfigureras och övergå när användarna som använder dem övergår.
Mer information om hur du konfigurerar var och en av funktionerna finns i motsvarande konfigurationshjälpartiklar.
-
Automatiska skötare — För att hantera automatiska skötare, se Automatiska skötare
-
Samtalsparkering - För att hantera samtalsparkering, se Call park
-
Upphämtning av samtal — Om du vill konfigurera samtalsupphämtningsgrupp finns i Upph ämtning av samtal
-
Samtalsköer - För att konfigurera samtalskö, se Samtalsk ö
-
Jaktgrupper — Om du vill hantera jaktgrupper finns i Hantera jakt grupp
-
Driftlägen - Om du vill dirigera samtal baserat på driftlägen, se Sam talsdirigering baserat på driftlägen
-
Personsökningsgrupper — Mer information om hur du konfigurerar en personsökningsgrupp finns i Konfigurera en personsökningsgrupp
-
Inspelningar - För att hantera samtalsinspelning för, se Hantera inspelningar
-
Räckvidd för enstaka nummer - Om du vill konfigurera räckvidd för enstaka nummer (kontor var som helst), se Konfigurera enstaka nummer
Acceptansprovning
Godkännandetestning säkerställer att den migrerade miljön uppfyller funktionskraven, fungerar som förväntat och levererar en sömlös användarupplevelse i alla kommunikationsflöden. Denna validerings process är mångfacetterad och täcker allt från användarprovisionering och nummertilldelning till operativa prestanda för avancerade samtal sfunktioner.
Det här avsnittet innehåller exempel och belyser viktiga aspekter att tänka på under godkännandetestning; i alla fall, det är inte avsett att fungera som en uttömmande eller omfattande checklista.
Tilldelning av användare och nummertilldelning
En grundläggande aspekt av acceptanstestning innebär att verifiera att alla användare är etablerade korrekt och fullständigt inuti. Detta kräver en grundlig jämförelse mellan source () -katalogen och den nyetablerade användarbasen för att säkerställa att varje användarkonto, tillsammans med tillhörande attribut som an knytningsnummer och DID-tilldelningar (Direct Inward Dip) har migrerats korrekt. Fullständigheten av provisioneringen är avgörande inte bara för driftbarheten dag ett utan också för pågående administration och support.
Validering av nummertilldelning inkluderar bekräftelse av att varje användare tilldelas rätt anknytning och externt nummer, och att dessa nummer dirigeras korrekt i både interna (på nätet) och externa (PSTN) samtalsflöden. Det är viktigt att kontrollera om det finns överlappningar, saknade tilldel ningar eller felkonfigurationer som kan leda till samtalsroutningsfel eller serviceavbrott.
PSTN-samtalsflöden och presentation av uppringnings-ID
Ett robust förfarande för acceptanstestning måste omfatta end-to-end- validering av PSTN-samtalsflöden. Detta inkluderar både inkommande och utgående samtalsscenarier. För inkommande PSTN-samtal bör testteamet bekräfta att samtal levereras till de avsedda slutpunkterna, oavsett om det är enskilda användare, samtalsköer, jaktgrupper eller automatiska sköer. Utgående PSTN-samtal måste göras framgångsrikt, med särskild uppmärksamhet på korrekt leverans och presentation av uppringnings-ID-information. Detta innebär att se till att rätt uppringarens namn och nummer visas för externa mottagare, i enlighet med organisationens policyer och myndighetskrav.
Testning bör också ta itu med failover-scenarier, till exempel hantering av oåtkomliga slutpunkter eller nätverksstörningar. Detta hjälper till att bekräfta att reserv mekanismer och alternativ routing fungerar korrekt, vilket upprätthåller tjänstekontinuitet och tillförlitlighet.
Samtalsflöden på nätet
Interna, eller on-net, samtalsflöden utgör ryggraden i företagskom munikation. Godkännandetestning i detta område verifierar att samtal mellan användare inom organisationen dirigeras korrekt, med funktioner som samtalsöverföring, kvarhållande, vidarekoppling och konferenser som fungerar som avsett. Integriteten för uppringningsplaner, anslutning mellan tillägg och tillägg och stöd för organisations samtalspolicyer måste alla bekräftas.
Hantering av användarsamtal och funktionsvalidering
En viktig aspekt av acceptanstestning innebär att validera hur användare hanterar samtal med hjälp av skriv bord stelefoner som stöds. Denna process fokuserar på att bekräfta att dagliga samtals flöden är intuitiva och pålitliga, och att användare har sömlös åtkomst till de kärn funktioner som är nödvändiga för deras roller. Testning bör bedöma hur enkelt användare kan ringa och ta emot samtal, hantera håll nings- och återupptagningsfunktioner, och utföra både blinda och rådgivande överföringar. Det är också viktigt att verifiera att vidarekoppl ing, konferenser och andra avancerade funktioner, såsom parkering och hämta samtal eller aktivera stör ej, är lättillgängliga och fungerar smidigt.
Upplevelsen bör utvärderas för tydlighet och lyhördhet, med tanke på hur användare interagerar med samtalshistorik, röstbrevlåda och integrerade kataloger. Ytterligare uppmärksamhet bör ägnas åt möjligheten att flytta aktiva samtal mellan enheter och att använda samtalskontroller effektivt inom applikationen eller på fysiska telefoner. Det slutliga målet är att säkerställa att slutanvändarupplevelsen är konsekvent, effektiv och fullt ut stöder organisationens kommunikationsbehov efter migreringen.
Samtalsköer: Erfarenhet av agent och handledare
Samtalsköer används ofta för att hantera scenarier för inkommande samtal med stora volymer. Acceptansprovning fokuserar här på flera dimensioner. Först bör det verifieras att samtal distribueras till agenter enligt den konfigurerade kölogiken, till exempel round robin, längsta tomgång eller samtidig ring. Presentationen av köade samtal på agentskrivbord måste undersökas för tydlighet och användarvänlighet, så att agenter effektivt kan acceptera, hålla och överföra samtal.
För handledare bör skrivbordsupplevelsen utvärderas för funktioner som realtidsövervakning, samtalspråkning och analys eller in sikter om köprestanda. Detta inkluderar men är inte begränsat till validering av instrumentpaneler och rapporteringsverktyg som tillhandahåller handlingsbara data om samtals distribution, agentaktivitet och kömätvärden.
Jaktgrupper: Samtalsfördelning
Jaktgrupper är en nyckelmekanism för att distribuera samtal till fördefinierade uppsättningar användare. Acceptanstestning måste bekräfta att samtal dirigeras till gruppmedlemmar baserat på den konfigurerade jaktalgoritmen, och att scenarier för överflöd, vidarebefordran och inget svar hanteras enligt design. Att säkerställa att gruppmedlemskap och samtalsroutningsbeteenden matchar de som tidigare fastställts i är avgörande för operativ konsistens och användartillfredsställelse.
Automatiska mottagare: Meddelanden och menyåtgärder
Automatiska skötare representerar frontlinjen för automatisk samtalshantering. Testningen måste omfatta uppspelning av meddelanden, noggrannheten hos inspelade hälsningar och korrekt funktion av menyträd. Meny val bör på ett tillförlitligt sätt dirigera uppringare till lämpliga avdelningar, individer eller externa nummer. Testning bör också innehålla ogiltiga scenarier eller timeout-scenarier för att bekräfta att uppringare får tydlig vägledning eller omdirigeras som avsett.
Röstbrevlådeoperation
Slutligen är röstbrevlådans funktionalitet avgörande för användarupplevelsen. Godkännandetester bör verifiera att röstbrevlådor är korrekt tilldelade och tillgängliga, både inifrån organisationen och på distans. Möjligheten att spela in, hämta och hantera meddelanden måste bekräftas, tillsammans med aviseringsleverans.
Optimera
PSTN-migrering till Cloud Connect för
När alla slutpunkter och användare har migrerats till molnanrop Unified CM är det enda syftet att fungera som en transit mellan PSTN-gateways och via Local Gateway. Att ta bort PSTN-gateways och Local Gateway från bilden genom att använda Cloud Connect som PSTN-åtkomst för alla Webex Calling användare har flera fördelar, inklusive kostnads minskning och förbättrad tillförlitlighet. Så här övergår du till lokal PSTN-åtkomst till Cloud Connect för :
-
Cloud Connect för partnerval.
Se listan över Cloud Connect för partners och välj bland de tillgängliga partnerna som är tillgängliga för din organisations plats.
-
Cloud Connect för validering.
Innan du byter PSTN-åtkomst för platser till Cloud Connect bör anslutningen till PSTN via den valda Cloud Connect-partnern verifieras och valideras. För detta ändamål måste en testplats etableras med vissa testanvändare etablerade på den testplatsen. PSTN-åtkomst för den här test platsen ställs sedan in på Cloud Connect-partnern innan PSTN-anslut ningen valideras med testtelefonerna. Efter lyckad validering kan testplatsen avprovisioneras.
-
Nummerportering.
För att förbereda för övergången till Cloud Connect måste en portorder för alla nummer som för närvarande är tilldelade PSTN-trunken som avslutas placeras. Alla nummer måste överföras till Cloud Connect-partnern. För att bibehålla åtkomligheten mellan lokaliseringar måste alla nummer på alla platser portas samtidigt .
-
Byt till Cloud Connect-partner.
Vid tidpunkten för övergången måste PSTN-åtkomst för alla platser i ställas in till Cloud Connected PSTN-leverantören, och inkommande och utgående anslutning bör verifieras.
Som diskuterats i avsnittet PSTN i designkapitlet kan kunder också välja att flytta sin PSTN-åtkomst till Cloud Connect för i början av övergången med hjälp av PSTN-trunking för hybriddistributioner. Mer information finns i PSTN-trunking för hybriddistributioner. Webex Calling I det fallet under övergången sker PSTN-åtkomst för via lokal gateway och efter att alla användare flyttats till finns det inget ytterligare PSTN-relaterat migreringssteg annat än avveckling och de lokala gatewayerna.
Optimera lokal infrastruktur
När alla användare har övergått till och alla slutpunkter har övergått till molnregistrering (eller har avvecklats ) uppdaterar du lämplig lokal infrastruktur nu när molnsamtal används. Uppdateringar av infrastrukturen inkluderar:
-
Ta bort lokala samtalskontroll- och meddelande DNS SRV poster från den lokala DNS-servern (erna) inklusive cisco_uds. _tcp. <domain>, cup_inloggning. _tcp. <domain>. Dessa SRV-poster krävs inte längre för identifiering av klienttjänster.
-
Ta bort kantrelaterade DNS SRV poster från det offentliga DNS-systemet inklusive collab_edge. _tls. <domain>. Dessa SRV-poster krävs inte längre för att upptäcka klienttjänster för gräns tjänster för samarbete.
-
Uppdatera alla relevanta DHCP-omfattningar för att ta bort alternativ 66 och alternativ 150 TFTP/startserveradresser. Dessa omfattningar krävs inte längre för identifiering och nedladdning av konfiguration av slutpunktssamtalskontroll.
-
Uppdatera/ta bort lämpliga uppringningspartners i Lokal gateway/kub som dirigerar samtal till och från. Unified CM Dessa uppringningspartners behövs inte längre för lokal samtalsdirigering.
-
Ta bort eller ta bort alla virtuella datorer och/eller servrar i klusternoder. Återanvänd beräkningsresurser och hårdvara efter behov. Dessa resurser behövs inte längre för samtalskontroll och edge-tjänster.
-
Ta bort eller ta bort alla virtuella datorer och/eller servrar i klusternoder. Återanvänd beräkningsresurser och hårdvara efter behov. Dessa resurser behövs inte längre för röstbrevlåda och enhetliga meddel andetjänster.
-
Rensning: Efter migrering av PSTN-åtkomst till Cloud Connected PSTN kan PSTN-trunkar, PSTN-gateways och Local Gateway avvecklas.
-
För alla befintliga lokala E911-lösningar tar du bort alla platser eller nummer som har migrerats till och när fullständig övergång är klar tar du bort virtuella programmaskiner eller servrar. Återanvänd beräkningsresurser och hårdvara efter behov. Dessa resurser behövs inte längre för nödsamtal och lokaliseringstjänster.
-
DN:er som tillhör migrerade användare bör placeras i en dold partition för att undvika fel på samtalsroutning och för att säkerställa att alla CSS-servrar har prioriterad åtkomst till molnsökvägen för samma DN:er.
-
Uppdatera den fysiska avsändningsplatsen och nätverkselementet i horisontmobilitet när förändringar inträffar. Vanliga aktiviteter som kräver uppdateringar är:
-
Byte av nätverksswitch
-
Ersättning av trådlös åtkomstpunkt
-
Ändringar av DHCP-omfattning
-
Fysiska förändringar inne i byggnaden (om de löses till kubikal/kontor)
-
Fysisk kontorslokalens expansion eller sammandragning inuti en byggnad.
-
Använd analys och felsökning
tillhandahåller omfattande analys- och felsökningsfunktioner som hjälper dig att visualisera och spåra din distribution. Dessa täcker mediekvalitet, detaljerad samtalshistorik, samtalskö, jakt grupp, och automatisk skötanalys. Ett exempel på mediekvalitetsanalys visas i figur mediekvalitetsanalys.
Under felsökning kan varje samtal som görs med hjälp av visas med detaljerad information om viktiga mediekvalitet och signalrelaterade problem för att hjälpa till att identifiera medieproblem såväl som misslyckade samtal, som visas i felsökning av medi ekvalitet i figuren.
Felsökning kan också integreras med andra Cisco-produkter som ThousandEyes och Meraki- switchar för att ge en ännu rikare integrerad upplevelse i Control Hub. Mer information om hur du använder Webex Callinganalys och felsökning finns i Felsöka Webex Calling samtal i Control Hub.
Innan du börjar
Den här guiden är avsedd för team eller individer med erfarenhet av att konfigurera och administrera Cisco Unified Communications Manager (Unified CM) och Cisco-slutpunkter, inklusive IP-skrivbordstelefoner, videoenheter och Jabbers mjukklienter. I hela detta dokument finns länkar till produkt- och supportdokumentation för att hjälpa till.
Detta dokument fokuserar endast på övergångar från Unified CM till Webex Calling flera hyresgäster. Termen Webex Callingi detta dokument hänvisar alltid till Webex Calling flera hyresgäster.
Innan migreringen från Unified CM till på Webex Calling börjas är det absolut nödvändigt att ha en omfattande förståelse för Webex Calling lösningen och dess respektive komponenter. En lyckad migrering kräver kunskap om Webex Calling arkitek turen, servicemodellerna, distributionsalternativen och tillhörande funktioner för att korrekt kartlägga befintliga Unified CM arbetsbelastningar och utforma en effektiv övergångsplan.
En grundlig förståelse av följande Webex Calling komponenter är avgörande för att informera om en effektiv övergångsstrategi och operativ beredskap.
-
Kontrollnav
-
Tillhandahållande av katalog och användare
-
Webex Callingplattform
-
Slutpunkter för samtal som stöds
-
PSTN-anslutningsalternativ
-
Webex Callinguppringningsplan och nummerhantering
-
Säkerhets- och efterlevnadsfunktioner.
Mer information finns i Cisco Preferred Architecture forWebex Calling.
Den här guiden belyser verktyg och processer som ska användas under hela övergångscykeln. Men en övergång från lokalt samtal,Unified CM, till en ny molnsamtalsplattform,Webex Calling, kan vara en betydande ansträngning med potentiella affärsmässiga, tekniska och komplexa utmaningar. För att hjälpa dig att övervinna dessa utmaningar har Cisco några olika alternativ tillgängliga för att hjälpa dig med din resa. Det är viktigt att granska informationen på Enterprise cloud call - Samtalsmigrering och förstå varje alternativ och hur vart och ett av dem eventuellt kan hjälpa dig med din egen migrering.
-
Webex-migreringsverktyg: självbet jäning, kostnadsfria verktyg inbyggda i Control Hub för att effektivisera din övergång till Webex Calling
-
Certifierade migreringsleverantörer: Cisco-validerade mjukvaru- och verktygsleverantörer som har utvecklat migreringslösningar för att hjälpa Webex-partners och kunder med komplexa och stora migreringar. Dessa lösningar kan hjälpa till att förenkla, hantera och påskynda övergången till Webex Calling
-
Webex Setup Assist: en Cisco-ledd migreringstjänst som guidar kunder och partners genom distributionen Webex Calling och konfigurationen, som behövs för att framgångsrikt migrera Unified CM användare och tjänster till. Webex Calling
Översikt
Med tillväxten av molnlevererade samarbetstjänster vill fler kunder flytta sina befintliga samarbetsarbetsbelastningar till molnet med tanke på löften om minskad total ägandekostnad, förenklad hantering, kontinuerlig leverans av funktioner, ökad skala och överlägsen tillförlitlighet som ingår i molnbaserade tjänster. När kunderna vill göra övergången från lokala samarbetstjänster till molntjänster är det viktigt för dem att förstå vad övergången innebär och vilka steg som krävs för att genomföra övergången.
Syftet med detta dokument är att ge vägledning för distribution för kunder som specifikt vill övergå från lokalt Unified CM till Webex Calling i molnet. Den här distributionsguiden förutsätter att läsaren har en grundläggande förståelse för samtalsövergången mellan Unified CM ochWebex Calling, inklusive vilka förändringar när den här övergången görs och vad skillnaderna är när samtalsbelastningen flyttas från lokalt till molnet. Innan du fortsätter, se till att du har granskat och känner till informationen på övergångskartan. Detta övergångskartdokument ger information om förändringarna och skillnaderna i denna övergång.
Som visas i figur Lokal samarbetsarkitektur: samtalskontroll och fjärråt komst innehåller en typisk lokal distribution olika samarbetsinfrastruktur komponenter i nätverket, en samtalskontrollplattform, en kantplattform, hårdvaru- och mjukvaru slutpunkter och i vissa fall även konferens- och schemaläggningsplattformar. I Cisco- arkitekturen skulle detta inkludera Unified CM samtalskontroll, Expressway för fjärråtkomst och business-to-business (B2B) edge-tjänster, Cisco Meeting Server/ Cisco Meeting Management för lokala konferenser, Unity Connection för röstmeddelanden och användarvänd maskinvara (Cisco IP-telefoner, Cisco Desk och Room video system) och programvara () IP-baserade slutpunkter. Cisco Jabber Dessa komponenter kan variera något i vissa miljöer, men detta är utgångspunkten för övergången som beskrivs i resten av detta dokument.
Arkitekturen som visas i figur Lokal samarbetsarkitektur: samtalskontroll och fjärråtkomst baseras på Preferred Architecture (PA) för Cisco Collaboration Enterprise On-Premises Deployments. Mer information om Enterprise On-premise finns i Ciscos föredragna samarbetsarkitekturer.
Före: Tabellen med lokala anropsinfrastrukturkomponenter visar nyckelelementen Webex Calling i den lokala arkitekturen innan övergången till molnet.
| Produkt | Beskrivning |
|---|---|
| Unified CM | Lokal samtalskontroll som tillhandahåller enhetsregistrering och samtalsdirigeringstjänster |
| Cisco Expressway-C/E | Edge-infrastruktur som tillhandahåller mobil- och Remote Access (MRA) och företag-till-företag (B2B) funktionalitet som gör det möjligt för fjärranslutna slutpunkter att ansluta säkert utanför organisationen . Expressway distribueras parvis för att tillhandahålla brandväggstra vering för externa slutpunkter. |
| Ciscos mötesserver (CMS), Ciscos möteshantering (CMM) och Cisco TelePresence Management Suite (TMS) | Lokal infrastruktur för röst-, video- och webbkonferenser som tillhandahåller flerpunktsmöten, möteshantering och schemaläggningsfunktioner. [Valfritt] |
| Cisco Unity Connection | Lokal röstmeddelandeplattform som tillhandahåller röstbrevlåda och enhetliga meddelandefunktioner. [Valfritt] |
| Cisco Desk, Cisco Room, Cisco Board, Cisco IP-telefoner och Cisco Jabber | IP-baserade enheter som är registrerade på Unified CM och som tillhandahåller röst- och videosamtalsfunktioner |
Som illustreras i Figur Övergångsbeslut: lokalt samtal till Webex Calling, kunder som har en lokal samtalskontroll med Unified CM och skrivbords- och video-IP-slutpunkter kan välja att övergå arkitekturen till en molnarkitektur. Webex Calling
Beslutet måste fattas utifrån kundens funktionskrav. Kunder som har följande krav bör överväga noga innan de fattar detta beslut och kan i slutändan besluta att behålla samtalskontrollen lokalt:
- Telefonmodeller stöds inte av Webex Calling
- Komplexa eller många integrationer med andra lokala system eller lösningar, särskilt där Webex Calling det är svårt att replikera dessa integrationer med eller inga motsvarande alternativa lösningar finns tillgängliga
- Komplex uppringningsplan, mycket detaljerade serviceklasser eller båda
- Begränsad, begränsad eller opålitlig internetåtkomst
- Stränga datasekretess- och ägarpolicyer
- Efterlevnadskrav för inspelning och lagring av media lokalt eller i landet
- Tredjepartsintegrationer utan genomförbar alternativ integration Webex Calling
- Kontaktcenterintegrationer där kontaktcenterintern inte flyttar till molnet ännu.
Det här dokumentet fokuserar på kunder med Unified CM samtalskontrolldistributioner som vill förstå de allmänna stegen, övervägandena och kraven för att möjliggöra Webex Calling distribution som beskrivs i nästa avsnitt.
Kärnkomponenter
Målarkitekturen för denna migrering innehåller flera nya komponenter. Detta inkluderar Webex Calling tjänsten för molnbaserade samtal, Webex App, Cisco Directory Connector för identitetsintegrering och Local Gateway (LGW) för PSTN- åtkomst, samt lokal till molnsamtalsintegrering. Ciscos samtalsplaner eller Cloud Connected PSTN (CCP) som underlättas av en Cloud Connect för Webex Calling partner är ytterligare alternativ för PSTN-åtkomst.
Som visas i Figur A fter: Webex Calling Architecture läggs de nya komponenterna (Webex Calling, Kataloganslutning, Lokal gateway och Survivalability-gateway) till i den befintliga lokala distribu tionen.
Efter: Tabellen för molnsamtalsinfrastrukturkomponenter visar de nya elementen i arkitekturen efter övergången till Webex.
| Produkt | Beskrivning |
|---|---|
| Webex Calling | Molnbaserad samtalstjänst som levereras från Webex-plattformen och tillhandahåller slutpunktsregistrering och samtalsdirigering |
| Cisco-kataloganslutning | Windows-program som körs på en Windows-domändator som tillhandahåller identitet
ssynkronisering mellan det lokala företaget Active Directory och identitetslagret
för Webex-organisationen. För kunder som flyttar från lokalt Active Directory till Entra ID använder identitetsintegrationen med Webex istället för Cisco Directory Connector appen Entra ID Wizard. |
| Lokal gateway | En lokal gateway fungerar som en bro mellan kundens lokala enhetliga kommunikationsnätverk och Webex Calling molnet. Det kan distribueras lokalt eller hostas av en partner, vilket ger PSTN- åtkomst för molnregistrerade slutpunkter samt samtalsintegration mellan registrerade och moln Unified CM registrerade slutpunkter. Cisco IOS-XE Integrated Services Router (ISR 1100- och 4000-serien), Cisco Catalyst 8200/8300-serien, Cisco Catalyst 8000V Edge- programvara och olika certifierade tredjeparts Session Border Controllers (SBC) kan användas som LGW för en stegvis migreringsmetod. |
| Gateway för överlevnadsförmåga | Survivalability Gateway (SGW) är en lokal IOS-XE-baserad gateway som tillhandahåller reservsamtalstjänster till slutpunkter på plats Webex Calling under nätverksavbrott. |
| Ciscos samtalsplan, Cloud Connect för Webex Calling | Cisco Calling Plan och Cloud Connect for Webex Calling är molnbaserade alternativ för PSTN-åtkomst för Webex Calling slutpunkter. PSTN-åtkomst underlättas av en PSTN-leverantör i molnet och kräver ingen lokal utrustning. |
| Webex-appen | Klientapplikation som körs på stationära OS (Windows, Mac) eller mobilt operativsystem (Android, iOS) och registreras direkt på Webex Calling plattformen för samtalsfunktionalitet. |
PPDIO processöversikt
PPDIO- processen står för Prepare, Plan, Design, Implementation och Optimize. Det är en strukturerad Cisco-metod som guidar projekt från första bedömning till kontinuerlig förbättring, vilket säkerställer effektiva och framgångsrika distributioner eller migreringar.
Allmän beskrivning av PPDIO
-
Förbered: Utvärdera den nuvarande miljön, samla in krav och anpassa intressenter för att skapa en solid grund.
-
Planera: Utveckla detaljerade projektplaner inklusive tidslinjer, resurser och riskreducerande strategier.
-
Design: Arkitektera mållösningen skräddarsydd för affärsmässiga och tekniska behov.
-
Implementera: Utför distributionen eller migreringen enligt designen, validera funktionalitet och prestanda.
-
Optimera: Förbättra lösningen kontinuerligt efter implementeringen genom att övervaka prestanda, förfina konfigurationer och utnyttja automatiserings- och integrationsverktyg.
Använda PPDIO för Unified CM att Webex Calling migrera projekt
Vid övergången från Unified CM till Webex Calling ger PPDIO-processen en tydlig färdplan för att säkerställa en smidig och effektiv övergång:
Förbered
-
Bedöma befintlig Unified CM miljö och migrationsberedskap
-
Samla in detaljerad data om användare, enheter, nätverk och beroenden
-
Samla in platsinformation inklusive nödsvarsadress, antal användare, internet åtkomst, PSTN-åtkomst
-
Identifiera risker och definiera projektets omfattning för att anpassa alla intressenter.
Planera
-
Skapa en omfattande migreringsplan med batchscheman, resurstilldelningar och tidslinjer
-
Definiera uppgifter som uppgraderingar av enhetens firmware, licenstilldelning och användarintroduktion
-
Koordinera migreringsfönster med Cisco och partners för att minimera störningar.
Utformning
-
Mappa aktuella Unified CM konfigurationer, uppringningsplaner och användarprofiler till Webex Calling motsvarigheter
-
Utforma Webex Calling miljön, inklusive PSTN-strategi (tillfällig och slutlig), platser, användarroller och integrationspunkter som lokal gateway (CUBE) och katalogsynkronisering
-
Planera för samexistensscenarier där Unified CM och Webex Calling fungerar samtidigt under migrering.
Implementera
-
Använd Control Hub-migreringsverktyg tillsammans med verktyg från tredje part för att utföra ändringar av enhetens firmware-läge, funktionskonfiguration och användarmigreringar
-
Använd massoperationer och provisionering med Webex API:er för att effektivisera storskaliga migreringar och konfigurationer
-
Utför licenstilldelning, enhetsregistrering och konfigurationsuppdateringar
-
Validera migreringsframgång genom testning och operativ verifiering.
Optimera
-
Kontinuer Webex Calling ligt övervaka prestanda och användarupplevelse
-
Förfina konfigurationer och arbetsflöden baserat på operativa data och feedback
-
Utnyttja automatiserings- och integrationsfunktioner för att förbättra effektiviteten och skalbarheten
-
Avveckla äldre Unified CM komponenter efter behov och ge kontinuerligt stöd för dag 2-operationer.
Detta förbättrade PPDIO-tillvägagångssätt säkerställer en kontrollerad, transparent och effektiv migrering från Unified CM tillWebex Calling, med hjälp av Ciscos verktyg, API:er och partnerekosystem för att upprätthålla affärskontinuitet och förbättra samarbetsförmågan.
PPDIO återkopplingsslingor
Högnivåöversikten som visas i figur iterationer medan PPDIO körs illustrerar en enda återkopplingsslinga från optim eringsfasen tillbaka till förberedelsefasen. Detta innebär att det, efter den första implementeringen, finns en kontinuerlig möjlighet till kontinuerlig förbättring. Varje optimeringscykel kan identifiera nya krav eller områden för förbättring, som kan hanteras genom efterföljande projekt eller initiativ. Dessa enskilda projekt följer i sin tur var och en den etablerade livscykeln PPDIO (Prepare, Plan, Design, Implement, Optimize). Detta iterativa tillvägagångssätt säkerställer att systemet förblir anpassat till utvecklande affärsmål och tekniska framsteg, vilket främjar en kultur av kontinuerlig förfining och anpassningsförmåga.
Under genomförandet av PPDIO-processen är det vanligt att resultat i de senare faserna kräver omprövning och eventuellt revidering av beslut som fattats i tidigare steg. Exem pelvis kan problem som uppstått under genomförandefasen, såsom identifiering av ok larheter i konstruktionen eller saknade detaljer, avslöja att vissa aspekter inte behandlades fullt ut under utformningsfasen. I sådana fall blir det nödvändigt att upprepa tillbaka till relevant tidigare fas för att lösa dessa problem innan du fortsätter. Denna iterativa återkopplingsm ekanism, som illustreras i figur Unified CMassisterad PPDIO-process säkerställer att lösningen valideras och förfinas noggrant, vilket i slutändan bidrar till en mer robust och effektiv distribution.
När man genomför en övergång från Unified CM till Webex Calling kan varje fas i PPDIO-processen dra stor nytta av information som samlats in från den befintliga Unified CM miljön. Till exempel kan omfattande inventeringar av användare, telefonnummer, samtals funktioner och uppringningsplanskomponenter extraheras från den aktuella Unified CM konfigurationen. Dessa data kompletterar information som tillhandahålls direkt av intressenter och hjälper till att effektivisera planerings- och designaktiviteter. Att utnyttja lämpliga verktyg för att automatisera dat autvinning och analys förbättrar inte bara noggrannheten utan påskyndar också den övergripande processen. Genom att utnyttja insikter från den befintliga distributionen Webex Calling kan övergången till utföras mer effektivt än en traditionell greenfield-implementering, samtidigt som den strukturerade PPDIO-metoden följs. Denna process illustreras i figur Unified CMassisterad PPDIO-process.
Migrationsstrategi
När du planerar din övergång från lokalt Unified CM tillWebex Calling, måste du bestämma hur du ska närma dig den här resan. Först måste du bestämma om migr eringen kommer att vara en flash-cut (allt på en gång) eller en stegvis strategi (migrera grupper av användare/enheter över en längre period).
Att göra en flash-cut- migrering flyttar alla dina användare och enheter snabbast. Med den här metoden flyttar du alla användare och enheter från lokalt Unified CM till Webex Calling samtidigt. I huvudsak är det ett enda migreringsfönster för alla användare och enheter. När migreringen är klar kommer alla dina användare och enheter att vara på Webex Calling plattformen och all din Unified CM infrastruktur kan avvecklas. Många organisationer kan dock inte använda det här tillvägagångssättet på grund av omfattningen och storleken på deras samtalsdistribution.
Det andra tillvägagångssättet är en ste gvis migration. De flesta organisationer kommer att använda detta tillvägagångssätt eftersom det ger bättre kontroll, hantering och skalning med migreringen. Det är också bättre lämpat för större UC-driftsättningar och/eller distributioner över flera regioner. Därför fokuserar detta dokument på det steg visa tillvägagångs sättet med två steg i övergången.
Som visas i figuren nedan Fas ad samtalsövergång: Hybrid och moln resulterar den första övergångsfasen (fas 1) i en samexistensdistribution med dubbla samtal smiljöer. I den här fasen övergår vissa användare, enheter och mjuka klienter till Webex Calling medan andra fortfarande är på den lokala samtalskontrollenUnified CM. Den sista övergångsfasen (fas 2) resulterar i en ren moln samtalsmiljö där alla användare, enheter och mjuka klienter har övergått helt till Webex Calling plattformen.
Hur lång tid det tar för en organisation att helt övergå till molnsamtal varierar beroende på dess nuvarande distribution. I vissa fall kan en organisation göra den första övergången och förbli i samexistens dubbla samtalskontrollfas (fas 1) under en längre period (månader eller till och med år), medan i andra fall kan en organisation helt övergå till Webex Calling (fas 2) på en mycket kort period (veckor eller månader). Detta dokument är avsett att täcka båda faserna (fas 1 - samexistens och fas 2 - fullständig övergång).
Det är möjligt att vissa organisationer kan upprätthålla en samexistens med dubbla samtalskontrolldistribu tioner på obestämd tid utan planer på att någonsin helt övergå till molnsamtal.
Det andra övervägandet är hur du överför användare, enheter och mjuka klienter från den lokala samtal skontrollen till molnsamtalskontrollen. Det rekommenderade tillvägagångssättet är en trefasad övergång . Figuren Rekommenderad 3-fasövergång nedan delar upp detta tillvägagångssätt i de tre faserna.
Förmigrering: Denna fas fokuserar på att göra både Webex och Unified CM miljöer redo för migreringen. Det handlar inte om att anropa specifik planering eller konfigurationer utan fokuserar på att slutföra aktiviteter som kan göras nu och innan ett Webex Calling migreringsprojekt startar. Målet är att bygga grunden för de två miljöerna för att förbereda sig för migreringen.
Migreringsförberedelser: I den här fasen inleds insatsen för att förbereda migreringen till Webex Calling. Här måste affärsmässiga och tekniska krav ses över och uppdateras. Gör inte bara ett lyft och skift av det som för närvarande distribueras med Unified CM utan omdefiniera istället de affärsmässiga och tekniska krav som ditt företag behöver idag och i framtiden genom att utnyttja kraften i. Webex Calling Dessutom är detta fasen där du kommer att slutföra din design, konfigurations planering och migreringsplanering/schema.
Migrering (utrullning och avveckling): Den här fasen sker den faktiska migr eringen av användare, enheter, telefonnummer och mjuka klienter. Som diskuterats ovan kan denna fas slutföras för alla samtidigt (flash-cut) eller över flera ändringsfönster (fas ad skärning). Slutanvändarnas antagningsplaner, utbildning och kommunikation är avgörande, så dina användare är medvetna om förändringarna, hur man använder den nya samtalsplattformen och vet när förändringen kommer att ske. Det sista steget är att avveckla all lokal UC-infrastruktur som inte längre används.
Förmigreringsfasen innehåller aktiviteter (obligatoriska, rekommenderade och valfria) som du kan börja arbeta med omedelbart. Det rekommenderas att slutföra dessa förr snarare än senare och helst innan ditt projekt börjar. Vissa av aktiviteterna kan ta längre tid att slutföra, så att starta dem tidigare hjälper det att effektivisera ditt faktiska migreringsprojekt.
Figuren Fö re migrationsaktiviteter nedan belyser fem specifika kategorier av aktiviteter som är relaterade till en Webex Calling migration.
Förbereda
Affärsmässiga och tekniska krav
När du planerar en migrering från till är det viktigt att noggrant samla in både tekniska och affärsmässiga krav under planeringsfasen. Detta steg säkerställer att migreringen överensstämmer med organisationens operativa mål och tekniska kapacitet, vilket minimerar risker och störningar.
Varför det är viktigt att samla krav:
-
Anpassar affärsmålen: Att förstå affärsbehov hjälper till att skräddarsy migreringen för att stödja viktiga arbetsflöden, användarupplevelse och tillväxtplaner.
-
Säkerställer teknisk kompatibilitet: Att identifiera tekniska krav tidigt förhindrar integrationsproblem med befintlig infrastruktur, nätverk och slutpunkter.
-
Underlättar resursplanering: Tydliga krav hjälper till att uppskatta tidslinjer, kostnader och nödvändiga resurser exakt.
-
Minskar risker: Ti dig upptäckt av potentiella utmaningar möjliggör proaktiva lösningar, vilket minskar driftstopp och serviceavbrott.
Affärskrav
Typiska affärskrav inkluderar:
-
Antal användare och platser som ska migreras
-
Önskade funktioner och tjänster (exempel samtalsdirigering, röstbrevlåda, konferenser, automatiska sköer, samtalsköer)
-
Policyer för efterlevnad och säkerhet
-
Budgetbegränsningar och kostnadsförväntningar
-
Användarutbildning och supportbehov
-
Överväganden om migrering och affärskontinuitetsöverväganden.
Att samla in önskade funktioner och tjänster är ett viktigt steg för att säkerställa att det nya systemet uppfyller affärsbehov. När du samlar in dessa krav är det viktigt att inte bara överväga vad som för närvarande är konfigurerat utan försöka samla in de faktiska kraven från de affärsenheter som ska använda systemet. Annars finns det en risk att planen bygger på långfristiga antaganden. Se till att utvärdera ytterligare eller förbättrade funktioner som är tillgängliga i som kanske inte finns i, till exempel molnbaserade samtal, avancerade samtalsköer, , och. Detta hjälper till att utnyttja alla fördelar med molnplattformen.
När du utvärderar den aktuella konfigurationen i, är det viktigt att inse att inte alla befintliga inställningar kan förbli nödvändiga på grund av förän derliga krav under hela systemets livscykel. Fokus bör ligga på att identifiera och behålla endast de konfigurationer som överensstämmer med de nuvarande och framtida behoven för implementeringen.
Fokusera mer på vad du behöver än vad du har.
Efterlevnads- och säkerhetspolicyer är viktiga överväganden under migreringen från Webex Calling till för att säkerställa att det nya molnbaserade kommunikationssystemet följer juridiska, regelmässiga och organisatoriska standarder.
-
Regelefterlevnad: Organisationer måste verifiera att de uppfyller branschspecifika bestämmelser som GDPR, HIPAA eller SOX, och ta itu med krav på datasekretess, lagring och hantering, samt landsspecifika mandat relaterade till datalägenhet, vägtullförbikoppling och medielokalitet.
-
Datasäkerhet: Säkerställa att röst- och signaldata krypteras både i transit och i vila för att skydda mot avlyssning eller obehörig åtkomst.
-
Åtkomstkontroller: Definiera och verkställa användarautentisering, auktorisering och rollbaserad åtkomst för att förhindra obehörig användning av kommunikationsresurser.
-
Granskning och övervakning: Im plementera loggnings- och övervakningsfunktioner för att spåra åtkomst och användning för efterlevnadsrevisioner och utredningar av säkerhetsincidenter.
-
Policyanpassning: Anpassa migreringen till befintliga företags säkerhetspolicyer, inklusive slutpunktssäkerhet, nätverkssegmentering och planer för hantering av incidenter.
-
Leverantörssäkerhetsförsäkring: U tvärdera Ciscos säkerhetscertifieringar och efterlevnadsintyg för att säkerställa tillförlitlighet.
Att hantera dessa efterlevnads- och säkerhetspolicyer under planeringsfasen hjälper till att minska riskerna, undvika rättsliga påföljder och upprätthålla integriteten och konfidentialiteten för kommunikationen under och efter migreringen.
Användarutbildning och supportbehov är viktiga komponenter under migreringen från till för att säkerställa en smidig övergång och användaradoption. Viktiga överväganden inkluderar:
-
Utbildningsprogram: Utveckla skräddarsydda utbildningar för olika användargrupper (slutanvändare, administratörer, helpdesk-personal) för att bekanta dem med funktioner, användargränssnitt och nya arbetsflöden.
-
Dokumentation: Tillhandahåll tydliga och lättillgängliga användarhandböcker, vanliga frågor och snabbreferens material, inklusive nyheter och olika resurser och steg-för-steg-instruktioner före och efter (i video- eller snabbguideformat), för att stödja användarna när de an passar sig till den uppdaterade upplevelsen efter migreringen.
-
Ändringshantering: Kommunicera förändringar proaktivt för att hantera användarnas förväntningar och minska motståndet.
-
Supportstruktur: Upprätta ett dedikerat supportteam eller eskaleringsväg för att hantera användarproblem snabbt under och efter migreringen.
-
Pågående utbildning: Planera för kontinuerliga utbildningsuppdateringar när nya funktioner eller uppdateringar släpps i.
-
Feedbackmekanismer: Implementera kanaler för användare att rapportera problem och ge feedback för att förbättra utbildnings- och supportprocesser.
Att hantera dessa utbildnings- och supportbehov under planeringsfasen hjälper till att minimera störningar, ökar användarnas förtroende, och maximerar fördelarna med att migrera till.
Tekniska krav
Flera viktiga tekniska krav måste samlas in och dokumenteras för en lyckad migrering från till, inklusive detaljer för
-
Nätverksberedskap och bandbreddskapacitet
En omfattande nätverksbedömning är avgörande för att säkerställa att din befintliga infrastruktur kan stödja den nya Webex Calling miljön. Detta inkluderar:
-
Bandbreddsanalys: U tvärdera aktuell och projicerad bandbreddsanvändning för att hantera röst-, video- och datatrafik utan trängsel.
-
Quality of Service (QoS): Implementer a QoS-policyer för att prioritera rösttrafik och minimera latens, jitter och paketförlust.
-
WAN- och internetanslutning: Kontrollera att WAN-länkar och internet anslutningar uppfyller kraven för molnbaserade samtal, inklusive redundans och failover-funktioner.
-
Brandvägg- och NAT-konfiguration: Se till att brandvägg- och NAT-inställningar tillåter nödvändig signalering och medietrafik för.
-
-
Integration med befintligt system
Sömlös integration med befintliga affärssystem är avgörande för användarupplevelse och kontinuitet i arbetsflödet:
-
Katalogtjänster: Utvär dera integrationen med en företagskatalog för automatiserad användarprovisionering och autentisering.
-
CRM och affärsapplikationer: Identifiera integrationspunkter med kund relationshanteringssystem och andra affärskritiska applikationer.
-
Äldre PBX-samverkan: Plan ering för samexistens eller stegvisa migrerings strategier om några äldre telefonisystem kommer att finnas kvar under övergången.
-
-
Slutpunktskompatibilitet och etablering
Alla slutpunkter inklusive skrivbordstelefoner, softphones och mobila enheter bör utvärderas med avseende på kompatibilitet :
-
Enhetsstöd: Bekräfta att befintliga IP-telefoner och enheter stöds av eller identifiera nödvändiga ersättningar.
-
Provisionsprocesser: Upprätt ande av automatiserade eller strömlinjeformade provisionering smetoder för effektiv onboarding av slutpunkter.
-
Firmware- och programuppdateringar: Planerar nödvändiga uppdateringar för att säkerställa driftskompatibilitet och säkerhet.
-
-
Säkerhetskonfigurationer och krypteringsstandarder
Säkerhet är av största vikt i molnkommunikation:
-
Kryptering: Genomför end-to-end-kryptering för signalering och mediaströmmar, i linje med Ciscos bästa säkerhetspraxis.
-
Autentisering och åtkomstkontroll: Implementera säkra autentiseringsm ekanismer (som SSO, multifaktorautentisering) och detaljerade användaråtkomst kontroller.
-
Överensstämmelse: Säkerställa att lösningen uppfyller relevanta regelverk och brans chstandarder (t.ex. GDPR, HIPAA).
-
Säkerhetsövervakning: Integrera med SIEM-verktyg och ställa in varningar för potentiella säkerhetsincidenter.
-
| Krav | Viktiga överväganden |
|---|---|
| Nätverksberedskap och bandbredd | Bandbredd, QoS, WAN/Internet, brandvägg/NAT |
| Integration med befintliga system | Katalog, CRM, PBX, E-post/kalender |
| Slutpunktskompatibilitet och etablering | Enhetsstöd, provisionering, firmwareuppdateringar |
| Säkerhetskonfigurationer och kryptering | Kryptering, autentisering, efterlevnad, säkerhetsövervakning |
| Användarutbildning och förändringshantering | Utbildningsprogram, dokumentation, förändringskommunikation |
| Nummerportabilitet och uppringningsplan | Nummermigrering/portering, uppringningsplanöversättning |
| Tredjepartsintegrationer | Personsökning, kontaktcenter, fax, analoga enheter |
Nätverksberedskap och krav
Nätverksberedskap är avgörande för en lyckad migrering till alla molnbaserade samtalslösningar som. Dålig nätverksplanering kan leda till försämrad samtalskvalitet, tappade samtal och missnöjda användare. Kunderna måste göra en nätverksbedömning innan de migrerar till. Det rekommenderas att bekräfta tillgänglighet för nätverksbandbredd för förväntad samtals volym, se till att kraven på servicekvalitet (QoS) uppfylls och förstå de olika portar som måste öppnas i kantbrandväggen (erna).
Tillförlitlig nätverksanslutning med tillräcklig servicekvalitet (bandbredd, paketförlust, RTT) är ett grundkrav för att säkerställa bästa möjliga användarupplevelse från början till slut för alla röst- och videokompatibla slutpunkter, klienter och applikationer som använder.
Kunder och partners har tillgång till anslutningsalternativ utöver OTT-internet (Over-the-Top) som kan optimera anslutningen till att inkludera Webex Edge Connect. Mer information om Webex Edge Connect- designdetaljer finns i Cisco Preferred Architecture for Webex Edge Connect forWebex Meetings, Calling Multi-Tenant och Dedikerad instans.
Kunder kan använda cScan för nätverksbedömning som ger information om kundens nätverkskvalitet, hur många samtal som kan upprättas, latens och så vidare. Mer information om cScan-verktyget finns i Använda cScan för att testa Webex Calling nätverk skvalitet.
Tänk på följande checklista för att säkerställa att nätverket är klart för migrering till:
-
Bandbreddsplanering
Beräkna samtidiga samtal per webbplats för att säkerställa att du har tillräckligt med uppströms och nedströms bandbredd och inkludera utrymme för annan affärskritisk trafik och framtida tillväxt.
Tabellen för beräkning av bandbredd för samtalstyp visar de samtalstyper som är tillgängliga med en distribution tillsammans med codec och maximal bandbredd som krävs för varje samtalstyp. Webex Calling Som visas i tabellen för beräk Webex Calling ning av bandbredd för samtalstyp som krävs för ljudsamtalsbandbredd för varje samtalstyp kan beräknas med hjälp av följande allmänna formel:
Antal förväntade samtidiga samtal* Bandbredd per samtal baserat på codec = Obligatorisk nätverksgenomströmning.
Tabell 2. Webex Callingsamtalstyp bandbredds beräkningar Samtalstyper Codec - bandbredd Bandbreddsberäkningar /Skrivbordstelefon -> OPUS - 70 kbps Antal samtidiga samtal* 70 kbps = Nödvändig nätverksgenomström ning /Skrivbordstelefon -> Skrivbordstelefon OPUS — 70 kbps Antal samtidiga samtal* 70 kbps = Nödvändig nätverksgenomström ning /Skrivbordstelefon -> PSTN via LGW G.711 — 80 kbps Antal samtidiga samtal* 80 kbps = Nödvändig nätverksgenomström ning /Skrivbordstelefon -> PSTN via Cloud PSTN (t.ex. Cisco-samtalsplan) G.711 — 80 kbps Antal samtidiga samtal* 80 kbps = Nödvändig nätverksgenomström ning /Skrivbordstelefon -> Enterprise via LGW G.722 — 80 kbps Antal samtidiga samtal* 80 kbps = Nödvändig nätverksgenomström ning /Skrivbordstelefon -> röstbrevlåda OPUS — 70 kbps Antal samtidiga samtal* 70 kbps = Nödvändig nätverksgenomström ning Genom att summera den samtidiga nödvändiga nätverksgenomströmningen per samtal styp kan det totala potentiella bandbreddskravet för en specifik plats bestämmas.
Alla samtalsben är alltid förankrade på åtkomstSBC: erna. För att bestämma den nödvändiga internetbandbredden för en viss plats behöver inte bara samtal mellan lokaliseringar beaktas, utan också samtal inom lokaliseringen och samtal till och från en lokal gateway på den platsen. Till exempel skulle ett samtal mellan två MPP-telefoner behöva upp till 2 x 70 kbps full duplex på platsens internetåtkomst.
Tabellen med exempel på Webex Calling bandbreddsberäkning visar ett exempel på en fullständig bandbre ddberäkningsövning, förutsatt att alla enheter finns på samma plats.
Tabell 3. Webex Calling exempel på bandbreddsberäkning Samtalstyper Antal samtidiga samtal Total bandbredd Webex-app/Skrivbordstelefon → Webex-app 15 2 * 15 * 70 kbps = 2 100 kbps Webex App/Skrivbordstelefon → Skrivbordstelefon 15 2 * 15 * 70 kbps = 2 100 kbps Webex-app/skrivbordstelefon → PSTN via LGW 50 2 * 50 * 80 kbps = 8 000 kbps Webex-app/skrivbordstelefon → PSTN via Cloud Connect för Webex Calling 0 0* 80 kbps Webex-app/skrivbordstelefon → Företag via LGW 15 2 * 15 * 80 kbps = 2400 kbps Webex App/Skrivbordstelefon → Webex Calling Röstbrevlåda 5 5 * 70 kbps = 350 kbps Totalt antal samtal/bandbredd 100 samtal 14 950 kbps/14,95 Mbps -
Alla bandbreddsvärden i tabellerna ovan hänvisar till IP-bandbredd. Länkbandbredden är högre beroende på WAN-inkapslingar.
-
Bandbredden i tabellerna ovan är för ljud samtal. För bandbredd för videosamtal stöder Webex App och MPP 8845/65-telefonerna H.264-video med maximal upplösning på 720p med en maximal bandbredd på 1 500 kbps per samtal. Mängden bandbredd som förbrukas när som helst under samtalet kommer dock att fluktuera baserat på variabel bithastighet som är inneboende i videokommunikation.
-
-
Servicekvalitet (QoS)
Implementera QoS-policyer i din lokala miljö för att prioritera trafik i realtid och se till att QoS upprätthålls över switchar, routrar och brandväggar.
-
Latens-, jitter- och paketförlustmål
Följande trösklar rekommenderas för optimal röst kvalitet när samtal går over-the-top (OTT) och över internet:
-
Latens - mindre än 100 ms enkelriktad
-
Jitter - mindre än 10 ms
-
Paketförlust - 0,5% eller mindre.
-
-
Brandvägg och NAT
Se till att brandväggen är konfigurerad för att tillåta trafik enligt listan i artikeln som finns på Portreferensinformation för Webex Calling. Tillåt dessutom åtkomst till domäner och IP-intervall som anges i samma guide och undvik SIP ALG eftersom det stör SIP-signalering. Medietrafik via proxyer bör undvikas.
-
DNS och NTP
Säkerställ korrekt DNS-upplösning av domäner och pålitliga NTP-servrar för att synkronisera enhetsklockor för TLS-certifikatverifiering och loggning.
-
Failover-planering
Tänk på befintliga leverantörsdataanslutningar (MPLS, SD-WAN och så vidare) och planera generellt för direkt internetåtkomst på varje plats i din distribution. Planera redundanta internet länkar där hög tillgänglighet krävs. Eftersom du kommer att konsumera molnbaserade tjänster är pålitlig internet anslutning med tillräcklig bandbredd ett bas krav. Du bör överväga att göra denna övergång om din organisations platsers internetanslutning (er) i allmänhet inte är tillförlitlig med låg latens och tillräcklig genomströmning upp och nedströms.
-
Webbplatsens överlevnadsförmåga
Webbplatsens överlevnad säkerställer att ditt företag alltid är tillgängligt, även om din nätverksanslutning går sönder. Site Survivalability använder en gateway i ditt lokala nätverk för att tillhandahålla en reservsamtalstjänst till slutpunkter på plats för situationer där nätverksanslutningen bryts. Överväg webbplatsens överlevnad med en lokal Sur vivalability Gateway (SGW) om affärskrav kräver kontinuerliga samtal i händelse av nätverksavbrott. För mer information om webbplatsens överlevnadskontroll, se Webbplatsens överlevnadsförmåga för. Webex Calling
Konfigurera molnansluten UC
Cloud Connected UC (CCUC) är en molnbaserad hanterings- och analyslösning utformad för att ge centraliserad synlighet, administration och insikter för distributioner både lokalt (somUnified CM) och molnet (). Det fungerar som en bro mellan traditionella lokala miljöer och Ciscos molntjänster och stöder organisationer under hela migrerings resan från till.
Under övergången till, CCUC spelar en viktig roll för att effektivisera migreringsprocessen genom att underlätta in samlingen av omfattande data från den befintliga Unified Communications-distributionen. CCUC hjälper till med viktiga övergångsuppgifter som migrering av enheter, funktioner och användar kontakter, samt automatisering av firmwareuppdateringar för IP-telefoner som stöds. Genom att tillhandahålla centraliserad synlighet och hantering hjälper CCUC till att säkerställa en smidigare och effektivare migreringsupplevelse.
Cisco rekommenderar starkt att CCUC distribueras och distribueras tidigt i övergångsprojektet, helst före eller under förberedelsefasen. Detta möjliggör de insikter och funktioner som behövs för att noggrant utvärdera, inventera och planera för efterföljande migrering saktiviteter och för att starta din resa till och framtida hybridfunktioner.
Bedömning av den nuvarande miljön
En viktig aktivitet i planeringen av migreringen är att bedöma den aktuella lokala miljön och distributionen. Detta ger insikter om vilka potentiella förändringar som kan krävas för att framgångsrikt övergå till. Det låter dig också bedöma de viktigaste elementen i plattformen jämfört med den befintliga lokala distributionen. Du kan använda den här informationen för att identifiera vilka specifika uppgifter som krävs för övergången och vilka ändringar du vill göra för att uppfylla dina affärs- och tekniska krav och användningsfall.
Följande aspekter är viktiga att granska som en del av denna insats.
Licensiering
Att förstå den nuvarande licensstrukturen för den befintliga distributionen är nyckeln när du förbereder dig för att migrera till. Utför en licensbedömning av följande områden i din befintliga lokala Cisco- lösning.
-
Plattform
Möjligheten att fullt ut formulera vad som för närvarande är licensierat på din kärnplattform kommer att vara avgörande när du arbetar med ditt kontoteam eller partner för att bestämma den bästa vägen till flex licenser. licensieras med flexlicensiering. Mer information om flexlicensiering finns i Cisco Collaboration flex plan.
-
Användare och enheter
Identifiera vilken licenskategori dina befintliga användare och enheter behöver. Detta kommer att användas för att avgöra vilken typ av licens som krävs för användarna och enheterna. erbjuder flera licenstyper, inklusive Professional- och Standard-licenser för användare och Professional- och gemensamma områdeslicenser för arbetsytor. Mer information om enhetslicensiering finns i databladet som finns på Enhetslicensiering.
-
Lokal gateway
Om Cisco Unified Border Element (CUBE) krävs för PSTN-åtkomst för denna övergång måste CUBE-licensiering också övervägas. CUBE-licensieringsöverväganden behandlas senare i detta dokument.
Platser/platser
Antalet och typerna av platser (stora centrala, regionala, filialer osv.) inom din befintliga distribution bör beaktas när du planerar denna övergång. En fullständig förståelse för de befintliga distributionsplatserna kommer att hjälpa till med strategisk planering för en framgångsrik övergång, särskilt när det gäller att bestämma vilka platser som ska migreras och i vilken ordning. Att i detalj förstå krav på uppringningsplan (numrering, uppringningsvanor, begränsningsklasser osv.), nätverksanslutning och bandbredd (Internet, WAN, LAN) och PSTN-åtkomst (lokal eller centraliserad, IP eller TDM) för varje webbplats kommer att vara avgörande när migreringsbeslut fattas. Mer information om vanliga distributionsmodeller och viktiga överväganden finns i informationen om distributionsmodeller för samarbete som finns i SRND för samarbete.
En annan viktig distributionshänsyn när du övergår till är platstillgänglighet. har olika funktioner, prenumerationer och enheter som är tillgängliga beroende på var distributionen finns. Mer information om geografisk tillgänglighet finns i Var är Webex tillgängligt? .
Slutligen är det viktigt att förstå vilken inverkan övergången till kommer att få på andra samarbetstjänster. Baserat på syftet med detta dokument är det allmänna antagandet att om befintliga samarbetstjänster utanför samtalsbelastningen ska bibehållas, förväntas övergången till fas 1-hybriddistributionen som nämns ovan. Exempel på samarbetstjänster som kan kräva hybriddistribution inkluderar lokalt kontaktcenter som ännu inte har migrerats till Webex kontaktcenter och snäva integrationer i system som personsökningssystem och fakturering. Mer information om övergången till ytterligare samarbetsarbetsbelastningar och tjänster finns i Samarbetsövergångar.
Inventera befintliga enheter/kunder
Innan övergången påbörjas är det viktigt att inventera dina befintliga hårdvaru- och mjukvaruslutpunkter. Om du har en fullständig lista över enhetstyper/modeller, maskinvaruversioner, operativsystemstyper och kvantiteter för mjuka klienter kan du planera på ett adekvat sätt för övergången av enheterna och minska effekten för de enheter som inte kan migreras till molnsamtal. Inventeringen bör användas för att bestämma vilka enheter som ska övergå och de enheter som ska bytas ut före över gången.
Skrivbordstelefoner
För ljud- och videobordstelefoner stöds endast skrivbordstelefoner i serien 6800, 7800, 8800 och 9800-serien. Detta är en delmängd av Cisco IP-telefoner som stöds med. Det finns vissa modeller och versioner av 6800, 7800 och 8800 telefoner som inte kan användas med. Mer information om vilka modeller och maskinvaruversioner som stöds finns i Enheter som stöds för Webex Calling.
Cisco 6800-seriens IP-telefoner kan inte uppgraderas från Enterprise-firmware till Multiplatform (MPP) firmware, vilket krävs för. Därför måste alla 6800-telefoner som är registrerade för firmware för företag ersättas med en 6800 MPP-modell eller med en annan telefonmodell som stöds.
Cisco 7800- och 8800-seriens IP-telefoner måste uppgraderas till MPP- firmware (Multiplatform Phone) innan övergången och registreras till. Om du vill ta reda på vilka 7800- och 8800-modeller och maskinvaruversioner som stöder MPP-firmware, se Konvertera IP-telefoner i Cisco 7800- och 8800-serien mellan Enterprise - och MPP-firmware.
8845, 8865 och 8865NR har nått slutet av försäljningen och rekommenderas inte att migreras till.
Äldre versioner av 8800-seriens telefoner (8811, 8841, 8851, 8851NR, 8861) rekommenderas inte att använda med. Webex Calling Telefoner med hårdvaruversioner VID 14 eller tidigare kommer att registrera sig med men kan uppleva vissa prestandaproblem på grund av hårdvaran.
9800-seriens bordstelefoner kör PhoneOS, som stöder både och registrering. Därför kan dessa telefoner övergå till utan en firmwareuppgradering.
Alla andra IP-telefoner måste bytas ut mot en 6800-, 7800-, 8800- eller 9800-serietelefoner som stöds av. Webex Calling Mer information om vilka IP- och skriv bordstelefoner som stöds finns i artikeln på Enheter som stöds för Webex Calling.
Videoslutpunkter
Personal- och rumsvideoslutpunkter, inklusive Cisco Board-serien, Room-serien och Desk- serien, kan SIP-registreras naturligt till. Alla dessa slutpunkter som behöver ringa ljud- och/eller PSTN-samtal kräver en samtalslicens:
-
Delade enheter i konferensrum, mötesutrymmen etc. kräver antingen en Professional Workspace eller Workspace-licens.
-
En slutanvändares personliga enhet kräver en professionell licens eller standardlicens.
Bestäm hur många videoslutpunkter som är registrerade på och används för att ringa ljudsamtal. Det är möjligt att vissa av videoslutpunkterna endast kan användas för att ansluta till möten eller ringa SIP-videosamtal. I båda fallen måste slutpunkterna fortfarande migreras till innan servrarna tas ur drift, men detta hjälper till att avgöra hur många av dem som behöver licenser för att fortsätta ringa telefonsamtal.
-
När videoenheter flyttas från registrering till ändras URI för dessa slutpunkter eftersom de nu är molnregistrerade.
-
Telefonmodellerna 8845, 8865 och 8875 är personliga video telefoner som stöds med.
Mjuka klienter
Det är den enda mjuka klienten som stöds av, till skillnad från Unified CM vilken stöder både Webex-appen och Jabber, och är den nya standardmjuka klienten för slutanvändare.
Beroende på driftsättningsläget (erna) som implementerats för Jabber (endast IM-, telefon- och/eller fullständiga UC-lägen) kan du också behöva överväga övergången av meddelandets- och/eller mötes arbetsbelastningarna från Jabber till. Den kan distribueras i telefonläge om den kommer att användas som en samtalsklient eller den kan distribueras som full Webex Suite om andra arbetsbelastningar, t.ex. Webex Messagingoch/ellerWebex Meetings, övergår till appen med samtal.
Det förbättrar slutanvändarens upplevelse genom att tillhandahålla AI-funktioner som ljud/videointelligens, samtalstranskription och andra. Mer information finns på https://www.webex.com/all-new-webex.
Innan du flyttar användare till måste du överföra sina Jabber-klienter till. Du har två alternativ för att slutföra denna övergång.
-
Innan du överför dem till
-
När du överför dem till.
För att underlätta den första övergången till, rekommenderas att använda alternativ 1 och flytta användare till med samtal först. Detta ger användarna tid att bekanta sig med den nya applikationen medan de fortfarande använder den befintliga lokala samtalsplattformen. När du är redo att flytta användare till konfigurerar du dem för att registrera sig på molnsamtalsplattformen.
För mer information om dessa två alternativ, se Migreringsresa - ett eller två steg? .
En fullständig lista över enheter som stöds för finns i Enheter som stöds för Webex Calling.
Verifiera enhetens behörighet
Som nämnts tidigare stöder en delmängd av Cisco IP-telefoner och kräver en annan firmwaretyp för telefonerna i 7800- och 8800-serien. Unified CMtelefoner kör Enterprise-firmware medan telefoner kör Multiplatform Phone (MPP) firmware. Det rekommenderas att kontrollera vilka registrerade telefoner som är berättigade att uppgradera till MPP-firmware under förberedelsefasen. Detta ger dig tid att ersätta icke-kvalificerade telefoner med en av de telefonmodeller som stöds eller att identifiera en alternativ plan, som att flytta en användare till endast Webex-appen.
Control Hub har ett inbyggt verktyg som heter Migrera din telefon till för att hjälpa till att avgöra om telefonerna är berättigade Webex Calling. När du använder det här verktyget för att kontrollera enhetens behörighet väljer du alternativet Migrering Generera endast enhetslicens.
Med det här alternativet kan du ladda upp en CSV-fil som innehåller telefonerna så att du kan kontrollera behörigheten för varje telefon. Genom att välja det här migreringsalternativet lägger det inte till telefonerna eftersom du fortfarande är i förberedelsefasen och inte är redo att göra detta ännu. Mer information finns i Migrera telefonen till Webex Calling.
Det är möjligt att vissa av telefonerna kan komma tillbaka med en okänd behörighet. Detta beror vanligtvis på att det inte går att validera viss information om telefonen i back-end-systemet. För alla telefoner som har status O känd har du två alternativ för att verifiera om de är berättigade att uppgradera till MPP-firmware.
-
Kontrollera varje telefon manuellt och verifiera modell- och hårdvaruversionen (PID VID)
7800/8800 telefonetikett med modell- och maskinvaruversionsinformation -
Använd Ciscos verktyg för beredskap för IP-telefoner
Ladda ner verktyget från https://github.com/joemar2/mpp_readiness_check.
Detta verktyg är inte ett officiellt Cisco-verktyg och det stöds inte heller TAC. Den har bästa ansträngnings stöd men är gratis att använda.
Det här verktyget måste köras på en dator som är lokal och kan komma åt servrarna och IP-telefonerna. Den har ett alternativ för att aktivera webbåtkomst på IP-telefonerna, vilket rekommenderas och behövs för att få bästa resultat. Därför bör den användas under lediga timmar för att undvika störningar för slutanvändarna. Utgången från verktyget ger en rapport som listar vilka av telefonerna i 7800- och 8800-serien som är berättigade att uppgradera till MPP-firmware. Eftersom den direkt kommer åt telefonen kan den verifiera de okända enheterna som rapporterades från Control Hub-verktyget.
Rapport om Cisco IP-telefonberedskapsverktyg
Användare
Ett av de viktigaste förberedelsestegen för att säkerställa att du har en lyckad migrering är korrekt användarprovisionering. Du måste planera ordentligt för alla användare även om du gör en stegvis migrering. Användare måste vara etablerade för något av följande:
-
Implementera med samtal
-
Distribuera med
-
Konfigurera tjänster för en användare
-
För att göra användare sökbara i katalogen (klicka för att ringa, Användarkontaktinformation, telefonkatalogsökning).
Vi rekommenderar att du tillhandahåller alla användare före eller i början av projektet. Detta inkluderar användare som fortfarande använder Unified CM för sin samtalsplattform är oberoende av sin samtalsenhet (IP-telefon, Jabber,). När användare migreras till (och/eller) uppdaterar du deras licenser för att aktivera de tjänster de behöver. Genom att etablera alla företagsanropande användare innan övergången påbörjas gör det möjligt för en användare som har övergått till eller att söka i katalogen efter en anropande företagsanvändare som fortfarande är på Jabber och/eller på. Detta säkerställer att övergångna användare kan hitta andra användares kontaktinformation och ringa till dem med hjälp av kataloguppslaget.
Sökningen i figur katalogen visar ett exempel på en användare som söker efter en annan användare. Sökresultaten visar användarens kontaktinformation och kan vara för en användare som fortfarande är på Jabber och eller för en användare som har övergått till och/eller.
Bestäm sedan vilka av de befintliga lokala samtalsanvändarna som ska övergå till. Om alla eller ett stort antal användare kommer att övergå rekommenderas det att flytta användare i grupper för att säkerställa att projektteam, IT-personal och supportpersonal kan hantera övergången och eventuella problem som kan uppstå. Du bör också avsätta lite tid för att tillhandahålla inledande information och utbildningar för att förbereda användarna för denna övergång. Användar övergångsgruppering kan göras baserat på en mängd olika kriterier, inklusive platsen eller webbplatsen som användare tilldelas, användaravdelningar eller till och med användartyper (kunskapsarbetare, chefer, mobila arbetare och så vidare).
Om användarna i distributionen till exempel är uppdelade på tre huvudplatser, New York (NYC), San Francisco (SFC) och Research Triangle Park (RTP), kan en användarövergångsplan se ut som den plan som beskrivs i Användarövergångsplan för platstabell.
| Användarwebbplats/plats | Information och utbildningar före övergången | Övergångsperiod | Stöd efter övergången |
|---|---|---|---|
| NYC (1 525 användare) | Vecka den 1 april | 15 april — 27 april | Vecka 29 april |
| SFO (1 600 användare) | Vecka Maj 6 | Maj 20 — Maj 31 | Vecka den 3 juni |
| RTP (1 275 användare) | Vecka den 3 juni | 17 juni - 28 juni | Vecka 1 juli |
En annan viktig faktor är att överföra användare tillsammans som har beroenden mellan varandra . Detta kan inkludera, men är inte begränsat till, följande:
-
BLF-övervakning
-
Samma jaktpilot/grupp
-
Dela rader
-
Ingår i samma samtalsupphämtningsgrupp
-
Använda samma call-park-nummer
-
Intercom
-
Administratör/Exec.
Du kan granska konfigurationen (GUI eller export) eller använda verktyget Migration Insights för att identifiera användargrupperna med dessa beroenden.
PSTN-anslutning
kan komma åt PSTN på tre sätt: Ciscos samtalsplaner, Cloud connect för (tidigare Cloud Connected PSTN) och lokal PSTN (lokal gateway). En enskild plats som definieras inom kan dock endast tilldelas ett enda PSTN-alternativ.
Lokalt PSTN med en lokal gateway (LGW) är en viktig del av övergångsstrategin. Det ger anslutning mellan den lokala distributionen och/eller PSTN och plattformen. stöder både Cisco och certifierade tredjepartssessionsgränskontroller (SBC) som kan användas som lokal gateway. För den senaste listan över SBC som stöds, se Lista över SBC som stöds.
stöder upp till 250 samtidiga samtal från en enda lokal gateway som är registreringsbaserad och mer än 250 samtidiga samtal från en enda lokal gateway som är certifikatbaserad. Certifikatbaserade lokala gateways kan stödja upp till 6500 samtidiga samtal, men detta baseras på vilken typ av anslutning den lokala gatewayen måste ha (Over-the-Top vs interconnect peering) och SBC-modellen som den lokala gatewayen distribueras på. Dessa gränser är i huvudsak standardräkningsgränsen för både lokala gateway-baserade PSTN-samtal och samtal mellan platser mellan och slutpunkter. Mer information finns i Kom ma igång med lokal gateway.
Alla samtal som överskrider denna gräns avvisas med 403 förbjudet. Det aktiva röstkommandot Visa samtal kan köras på den lokala gatewayen när som helst för att bestämma det totala antalet aktiva samtal.
Dåliga nätverksförhållanden mellan en lokal gateway och åtkomstSBC kan begränsa signalanslutningens prestanda, vilket leder till en ännu lägre gräns för samtidiga samtal. Envägs latens mellan den lokala gatewayen och datacentret bör inte överstiga 100 ms och jitter bör vara mindre än 10 ms medan paketförlusten är mindre än 0,5%.
Funktioner och funktionsanvändning
Vid bedömning av den aktuella miljön är det viktigt att identifiera och granska vilka funktioner som är konfigurerade. Dessutom är det viktigt att förstå användningen av funktionerna så att du kan (åter) definiera dina affärs- och tekniska krav för din distribution.
För att avgöra vilka funktioner som är konfigurerade analyserar du konfigurationen. Detta är alla statiska data som ställs in när en funktion eller inställning konfigureras på systemet. Följande alternativ kan användas för att slutföra denna analys:
-
Granska konfigurationen i admin GUI
-
config export - bulkexport eller AXL
-
verktyg för migreringsinsikter (rekommenderas)
-
Cisco tredjepartspartnerverktyg (rekommenderas).
För att analysera funktionsanvändning effektivt är det viktigt att undersöka dynamiska systemdata som användning, registreringar och samtal saktivitet. Olika analysverktyg och instrumentpaneler ger insikter i dessa mätvärden, vilket möjliggör en omfattande förståelse av systemets prestanda och kapacitet, vilket stöder informerat beslutsfattande under migrering och optimering. Följande alternativ kan användas för att slutföra denna typ av analys:
-
Granskning av råa CDR-poster
-
Granskning av Unified CM RTMT-data
-
Migration Insights verktyg med CDR-data
-
Granskning av molnansluten UC-analys i
-
Samtalsvolym
-
Registrerade slutpunkter
-
(CAC) platser
-
Stomutnyttjande.
-
-
Ciscos partnerverktyg från tredje part.
Cisco rekommenderar att du börjar med verktyget Webex Control Hub Migration Insights för den här analysen. Du importerar din export.TAR-fil och Unified CM CDR-filer (valfritt, men krävs för analys av funktionsan vändning) till verktyget. Verktyget genererar följande CSV-baserade rapporter som kan användas för att starta analysen:
| Rapportens namn Rapportbeskrivning |
|---|
| ImportedDataBulk.csv
Alla användare och enheter från Unified CM data |
| DeviceEligibility.csv
Identifierar enheter som är berättigade att migrera till Webex Calling (IP-telefoner, Room OS- enheter, ATA och tredje part) |
| DevicePoolNumbers.txt Lista över alla nummer i en viss enhet spool |
| HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv Detaljer om enheter och användare som ska migreras tillsammans baserat på delade linjer, jakt pilot, samtalskö, samtalspark och samtalsupphämtningsgruppskonfiguration |
| HuntGroupMigrationInsight.csv Detaljerad information om tilldelade jakt linjer, linjegrupper och tillhörande agenter |
| SharedlineGroupMigrationReport.csv Översikt över hur telefonnummer (katalognummer) delas mellan användare |
| Rapportens namn Rapportbeskrivning |
|---|
| FeatureUsageBasedDeviceEligibilityReport.csv Information om behörighet för enhetsmigrering baserat på funktionsanvändning |
| FeatureUsageWithLastUsageDateReport.csv Användningsantal för antalet gånger jaktpilot (er) och samtalskö (er) har anropats tillsammans med det senaste användnings datumet |
| UserWorkspaceLastUsage.csv Senaste användningsdatum för användare och arbetsytor för både mjuka klienter och hårdtelefoner |
| DIDUsageReport.csv DID-användning för både tilldelade och otilldelade DID |
Mer information om rapporterna Migration Insights finns i Migrering sinsikter.
Om du behöver mer information om funktionerna och användningen efter att ha granskat informationen i Migration Insights-rapporterna rekommenderar Cisco att överväga ett av Ciscos tredjepartsmigreringsverktyg för partners och/eller att granska konfigurationerna i användargränssnittet eller i konfigurationsexportdata.
Cisco-integrationer: Unity-anslutning UCCX UCCE
Röstbrevlådan är en integrerad del av erbjudandet och inbyggd i lösningen. kan inte integreras med en lokalbaserad röstbrevlådelösning som Unity Connection eller Unity Connection Express. Ytterligare, det finns inget inbyggt sätt att migrera befintliga röstmeddelanden eller hälsningar för Unit y-anslutning till den inbyggda röstbrevlådetjänsten som är tillgänglig med. Vissa av Ciscos tredjepartspartners migreringsverktyg har kapacitet att migrera en del av dessa data. Mer information om röstbrevlåda för finns i Konfigurera och hantera röstbrevlådeinställningar för en användare. Webex Calling
stöder också delade röstbrevlådor och faxbrevlådor. Mer information finns i Hantera en delad röstbrevlåda och inkommande fax box för. Webex Calling
har en inbyggd Auto Attendant-funktion som ingår som en del av kärnplattformen. Den här funktionen möjliggör övergång av din Unity Connections samtalshanterare och automatisk skötarfunktion. Verktyget Control Hub, Migrera funktioner frånUnified CM, stöder migrering av Unity-anslutningskonfigurationer till Auto-skötare. Mer information om hur du använder det här verktyget finns i Migrering av enheter och funktioner från Unified CM tillWebex Calling.
Samtalsinspelning
innehåller två alternativ för samtalsinspelning utan extra kostnad.
-
Webex samtalsinspelning
-
Dubber Go inspelning (partnererbjudande) - en integration mellan och dubber där alla inspelade media förvaras säkert i molnet.
Inkluderad inspelningsalternativ tabell belyser några viktiga funktioner i de två samtalsinspelningsalternativen som är tillgängliga utan extra kostnad.
| Webex | Dubbel Go |
|---|---|
| Tillgängligt för alla användare | Tillgängligt för alla användare |
| Obegränsat antal inspelningar | Obegränsat antal inspelningar |
| 1 års lagringstid* | 30-dagars lagringsperiod |
| 100 GB lagringsutrymme per organisation | - |
| Compliance-ansvariga kan komma åt och hantera samtalsinspelningar | - |
| API: er för att hantera inspelningar | - |
Administratörer kan konfigurera och hantera användarnas åtkomst till sina samtalsinspelningar
|
Endast användare kan komma åt och hantera sina inspelningar
|
Om din organisation kräver ytterligare inspelningsfunktioner som inspelning av efterlevnadssamtal, längre lagringsperioder, mer lagring, AI-analys och/eller administratörsåtkomst, finns det betalda erbjudanden eller tillägg från både Cisco och tredjeparts inspelningsleverantörer. Mer information om inspelningsleverantörer, konfigurationer och tilläggspartnertjänster finns i Hantera samtalsin spelning för Webex Calling.
Integrationer från tredje part
stöder en mängd olika tredjepartsinte gr ationer inklusive men inte begränsat till SBC: er för lokala gateways, IP-telefoner, intercom-telefoner, högtalare/personsökare, ATA, etc. Förutom dessa tredjepart sen heter, Webex Calling stöder olika tredjepart slösningar för kundsupport, analys, inspelning, fakturering etc. Mer information om tredje part slösningar finns i Webex App Hub.
Planera
Projektplan på hög nivå
När man utvecklar en projektplan på hög nivå för migrering från till, är det viktigt att fastställa tydliga faser och milstolpar som överensstämmer med både affär smål och tekniska krav. Planen bör inledas med en omfattande utvärderings fas, inklusive insamling av detaljerade tekniska och affärsmässiga krav, samt identifiering av intressenter och definition av framgångskriterier. Viktiga överväganden inkluderar resur sallokering, tidslinjeuppskattning, riskhantering, och kommunikationsstrategier för att säkerställa att alla parter är informerade och engagerade under hela migreringen. Dessutom bör planen innehålla valideringskontrollpunkter som pilottestning och stegvis utrullning för att minimera störningar och möjliggöra justeringar baserade på feedback.
Exempel på element som ska inkluderas i projektplanen är:
-
Definiera omfattningen av migreringen (t.ex. vilka användare, enheter och funktioner som ska övergå)
-
Schemalägga utbildningar för slutanvändare och supportteam
-
Samordna bedömningar av nätverksberedskap, och
-
Planering för cutover-aktiviteter med fallback-alternativ. Det är också viktigt att integrera efterlevnads- och säkerhetsgranskningar samt stöd- och optimerings faser efter migrering.
Genom att strukturera projektplanen med dessa överväganden kan organisationer bättre hantera komplexitet, minska riskerna och uppnå en smidigare övergång till.
Migrationsresa - ett eller två steg?
kräver att användare använder den för att ringa mjukklienten. Därför, om några användare fortfarande använder, har du två alternativ när du kan flytta dem till. Du kan antingen göra en användarmigrering i ett steg eller en användarmigrering i två steg.
Alternativ 1: Migrering av användare i ett steg
I en enda stegsmigrering övergår användarna från till samtidigt som de övergår från Unified CM till. Det här alternativet är vanligtvis för kunder med ett litet antal användare att migrera och kan hantera att flytta både användarens mjuka klient och samtalstjänst till samtidigt. Siff ran Användarens samtalstjänst, mjukklient och telefon migrerar till samtidigt nedan belyser denna typ av migration. Med det här alternativet kommer en användare att ha följande slutfört samtidigt:
-
Samtalstjänster flyttade från till
-
Telefonnummer och tillägg flyttades från till
-
Mjuk klient övergick från Jabber till - kommer att registrera sig till
-
Telefonregistrering flyttades från till.
Detta kan fortfarande vara en stegvis migrering där grupper av användare flyttas vid olika tidpunkter, men när varje användare flyttas sker alla dessa samtidigt.
Alternativ 2: Migrering av användare i två steg
Det andra tillvägagångssättet är en tvåstegsmigration. I steg 1, användare övergår från till men stannar kvar för samtalstjänster. Sedan i steg 2 flyttas användare från Unified CM till. Det här alternativet rekommenderas för större kunder för att hantera slutanvändarändringarna och vill skilja användarens mjuka klientändring från ändringen av samtalstjänsten. Följande bild Migrera mjukklient; sedan migrera samtalstjänst, mjukklient och telefon till Webex Calling nedan belyser den här typen av migrering.
Steg 1
-
Mjuk klient övergick från till - kommer att registrera sig till.
Steg 2
-
Samtalstjänster flyttade från till.
-
Telefonnummer och tillägg flyttades från till.
-
registreringen flyttades från till.
-
Telefonregistrering flyttades från till.
Detta kan fortfarande vara en stegvis migrering där grupper av användare flyttas vid olika tidpunkter i båda stegen.
Vilket alternativ du väljer beror på hur du vill hantera användarnas övergång till och. Rekommendationen är att ta det i steg (alternativ 2). Detta gör att du kan minimera slut användarens ändringar på en gång och dela upp ansträngningen över olika delar av projektet. Men om du föredrar att användare bara påverkas en gång, är det också giltigt att använda Alternativ 1.
Om du tittar på den rekommenderade resan (alternativ 1) visar över gångskartan Jabber till Webex App på hög nivå nedan övergången på hög nivå för steg 1.
I det här steget övergår användarna från Jabber till för alla sina samtalstjänster. Samtalsplattformen är dock fortfarande Unified CM och kommer att registrera sina samtalstjänster till. Som framgår av övergångskartan Jabber till Webex App på hög nivå ändras inte den lokala infrastrukturen och fungerar på samma sätt som Jabber gör. Den enda förändringen är att den kräver en anslutning till.
Mer information om den här övergången finns i Jabber till Webex övergångskarta och distribu tionsguide under Klient på sidan Över gång för samarbete.
Unified CMtill över Webex Calling gångskart figur på hög nivå är över gången på hög nivå från till. Detta är steg 2 av den rekommenderade resan.
Om du väljer att använda enstegsmetoden gäller detta också.
I det här steget övergår användarna till i grupper. Vid denna tidpunkt börjar användarna använda för sina samtalstjänster, samtalsregistrering och IP-telefonregistrering.
Eftersom användare flyttar i grupper kommer Enterprise-användare att delas mellan de två samtalspl attformarna under övergången. Fas 1 in Unified CMtill över Webex Calling gångskart figur på hög nivå visar detta tillstånd. Under denna fas krävs planering för hur man hanterar samtal mellan användare på de två plattformarna och hur PSTN-samtal kommer att dirigeras. Varje gång en grupp användare övergår till krävs uppringningsplaner och uppdateringar av samtalsrutning på, och den eller de lokala gatewayerna.
När alla användare, mjuka klienter och enheter har övergått till (fas 2) kan all lokal UC-infrastruktur tas bort och avvecklas.
Utformning
Val av region
är tillgänglig globalt och levereras från redundanta datacenter i flera regioner: USA (Dallas, Chicago), Kanada (Vancouver, Toronto), Europa (Frankfurt, Amsterdam), Storbritannien (London, Manchester), Australien (Melbourne, Sydney), Japan (Tokyo, Osaka), Saudiarabien (Riyadh, Jeddah) och Indien (Mumbai, Chennai). Media-POPs tillhandahåller medietjänster för att optimera mediernas rundturstider. Singapore-datacentret används till exempel för att optimera media rund turstiderna för kunder i asiatiska länder där rundturstiderna till antingen Australien eller Japan kan vara suboptimala. Datacentren är sammankopplade med en multi-gigabit och helt redundant ryggrad. Siff ran globalt distribuerade datac enter visar en översikt över alla datacenter. För den senaste listan över tillgängliga datacenter, se Datacenterplatser för Webex Calling.
Varje kund är etablerad på en av instanserna. All provisioneringsinformation för den kunden lagras i den instansen och SIP-signaleringen för alla slutpunkter och lokala gateways som är etablerade för den kunden är knuten till den instans kunden är etablerad på. Eftersom det är svårt att ändra det ursprungliga regionvalet är det viktigt att beakta alla relevanta faktorer som en del av besluts processen som leder till regionvalet. För att undvika överdriven signalering rundtursfördröjning är det viktigt att tidigt i övergångsprocessen bestämma vilken instans som ska användas. Cisco rekommenderar att du väljer den instans som ger de lägsta signaleringstiderna för det största antalet användare inom distributionen.
För tillgänglighet i länder, se Var är Webex tillgängligt? .
Platser
För att förbereda för tillhandahållande av platser måste den information som krävs för alla migreringsmål samlas in. Informationen som behövs för varje plats sammanfattas i Information som ska fångas för varje plats.
| Informationen | Kommentera |
|---|---|
| Förlängningsintervall | Varje plats i kan ha tillägg som börjar med olika siffror. En siffra måste sparas för
styrsiffran mellan olika platser (till exempel 8) och en för PSTN-
styrsiffran (till exempel 9). Inget förlängningsområde kan börja med någon av
dessa två siffror. Alla förlängningsintervall på alla platser måste vara lika långa. |
| DID-intervall | - |
| PSTN-styrsiffra | - |
| Webbplatskod | Alla webbplatskoder på alla platser måste vara unika och ha samma längd. |
| Huvudnummer | När du skapar en plats måste två DID: er etableras. Ett som
huvudnummer (till exempel för att tilldelas en automatisk mottagningstjänst) och ett för röstbrevlå
deportalen. Bestäm en DID för röstbrevlådans nummer. |
| Röstbrevlådanummer | |
| Antal licenser | Obligatoriska licenser efter typ inklusive Standard, Professional, Workspace, Ruttlista, Utgående samtalsplan. |
| Samtidiga samtal under den hektiska timmen | Summan av samtidiga samtal mellan enheter och mellan enheter och den lokala gatewayen (PSTN och samtal till enheter). Behövs för att bestämma den nödvändiga bandbredden för internetåtkomst. |
| Land | - |
| Tidszon | - |
| Språk | - |
| Kontakt (Namn, Telefon, E-post) | - |
| Adress (Gatuadress, Stad, Stat, Postnummer) | - |
| Räddningstjänstens fysiska avsändningsplats för slutpunkter | Enhetens avsändningsplats som används för nödsamtal inkluderar i allmänhet följande: byggnadsadress, byggnadsadress+våningsnummer, byggnadsadress+ svitnummer eller byggnadsadress+våningsnummer+kontor/kubiskt nummer. |
| Unik fysisk nätverksplats per enhet för räddningstjänster | Fysisk nätverksplats för nödsamtal omfattar i allmänhet följande: switch/switchport för trådbundna enheter, BSSID (Wireless Access Point) Basic Service Set Identifiers (BSSID) för trådlösa anslutna enheter och/eller lokala IP-delnät för slutpunktsenheter. |
PSTN
När kunderna utformar en driftsättning har kunderna tre primära PSTN-anslutningsalternativ: Cisco C alling Plans (en molnlevererad PSTN-tjänst som hanteras av Cisco), Cloud Connec ted PSTN Providers (CCPP, där leverantörer levererar PSTN-tjänster via molnet) och lokalt PSTN (där lokala gateways ansluter företagsnätverket till PSTN). Med införandet av PSTN-trunking för hybriddistributioner (för mer information, se PSTN-trunking för hybrid Webex Calling distributioner vid PSTN-trunking) får organisationer ytterligare flexibilitet i sin migreringsstrategi. Den här funktionen gör det möjligt för kunder att flytta sitt PSTN till CCPP i början av övergångs resan och börja övergå till moln-PSTN för användare, samtidigt som de utnyttjar CCPP för att upprätthålla PSTN-tjänsten för användare som förblir på Cisco under en stegvis migrering.
Detta hybridtillvägagångssätt gör det möjligt för organisationer att flytta utvalda användargrupper till molnet först, utan att omedelbart göra en översyn av hela telefonimiljön. Det introducerar dock ytterligare komplexitet och risk, särskilt när det gäller att anpassa befintlig samtalsroutningslogik för att stödja den nya arkitekturen. Interoperabilitet med äldre applikationer, till exempel faxservrar, kontaktcenter eller personsök ningssystem, kräver också noggrant övervägande. Viktiga tekniska utmaningar kan vara att säkerställa sömlös end-to-end-codec-förhandling och DTMF-signalering (Dual-Tone Multi-Frequency) över den blandade miljön, samt validering av kompatibilitet med specialiserade telefonfunktioner. Korrekt planering och testning är avgörande för att minimera störningar och upprätthålla tillförlitliga rösttjänster under hela migreringsprocessen. Dessutom är kommersiella överväganden viktiga, eftersom hybridtrunkning kräver en användningsl icens som baseras på antalet samtidiga samtal mellan den lokala miljön och Cloud Connec ted PSTN Provider (CCPP).
Alternativt kan organisationer välja att behålla sin lokala PSTN-anslutning under hela övergångsfasen. I det här scenariot kan migrering till CCPP utföras på två sätt: som en enda, samordnad cutover för alla användare och platser när migreringen är klar, eller stegvis, med PSTN-migrering per plats när användare flyttas till. Detta tillvägagångssätt kan hjälpa till att effektivisera samexistensen och upprätthålla kontinuitet för äldre integrationer, men det introducerar flera operativa komplexiteter. Bland dessa är utmaningar relaterade till nummerportering, såsom behovet av exakt samordning av nummerportorder, potentiella förseningar, och leverantörsinställda begränsningar som ett tak på antalet samtidiga portförfrågningar eller begränsningar för att portera delmängder av stora antal block. Organisationer måste noggrant planera sin PSTN-övergångsstrategi och ta hänsyn till dessa logistiska överväganden för att undvika serviceavbrott och säkerställa en smidig migreringsupplevelse.
Figuren Migrering till CCCP i början jämfört med att behålla lokalt PSTN visar de två PSTN- migreringsalternativen som förklaras ovan. Illustrationen till vänster visar scenariot där alla lokala användare och program använder moln anslutna PSTN-tjänster via en lokal trunk och en lokal gateway som ansluter den lokala till medan illustrationen till höger visar scenariot där den befintliga lokala PSTN förblir på plats och användare använder lokal PSTN via den lokala gateway-anslutningen mellan lokala Webex Calling enheter . och. Under övergången kan platser bytas till med Cloud Connected PSTN.
I båda scenarierna använder samtal mellan lokal och användare den lokala gateway-anslutningen. Anslutningen mellan lokalt och måste utformas och dimensioneras i enlighet med det förväntade antalet samtidiga samtal och den nödvändiga redundansen.
Uppringningsplan
För att uppnå sömlös interoperabilitet mellan och under migreringsperioden måste en omfattande uppringningsplanarkitektur utvecklas och implementeras på båda plattformarna. Denna uppringningsplandesign med dubbla plattformar säkerställer konsekvent samtals dirigering, nummeröversättning och funktionsinsyn, vilket gör det möjligt för användare på båda systemen att kommunicera utan försämring av tjänsten eller störningar i användarupplevelsen under hela samexistensfasen.
Lokal uppringningsplan i
Under övergången för att möjliggöra samexistens mellan enheter som är registrerade på Unified CM och på företaget måste uppringningsplanen ändras så att åtminstone följande krav kan uppfyllas:
-
+E.164 uppringning från till
-
Anslutningsuppringning från till (inom webbplatsen men även mellan platser om tilläggsområdena är unika)
-
Förkortad uppringning mellan webbplatser från till
-
Tvingad uppringning på nätet från till
-
Återuppringning från katalogen för missade samtal till destinationer på
-
PSTN-anrop från till PSTN om under övergången används lokalt PSTN för
-
PSTN-anrop från till om under övergången PSTN-trunking för hybriddistributioner används för att ge PSTN-åtkomst till lokala användare via Cloud Connect för
-
Tvingad på nätet från till
-
Anslutningsuppringning från till (mellan webbplatser).
Om något av ovanstående inte stöds uppringningsvanor före övergången, till exempel finns det ingen förkortad uppringningsvana mellan webbplatser, behöver de inte nödvändigtvis inför as under övergången.
Figuruppringnings planen för bästa praxis visar den bästa metoden för uppringningsplan enligt beskrivningen i Preferred Architecture for Cisco Collaboration 12.x Enterprise On-Premises Deployments, CVD. Viktiga egenskaper hos detta tillvägagångssätt inkluderar:
-
Enkel partition för+E.164 katalognummer
-
Kärnrouting baserad på+E.164 ruttmönster
-
Normalisering av alla uppringningsvanor till+E.164 med hjälp av översättningsmönster
-
Användning av översättningsmönster som anropar sökutrymmesarv (alternativ Använd upphovsmannens anro pssökutrymme inställ t på översättningsmönster).
Till exempel kommer PSTN-uppringning (9+1+10D) från en enhet i SJC som är etablerad med söku trymme för linjeanrop SJCinternational först att matchas av översättningsmönstret 9.1 [2-9] XX [2-9] XXXXXX som normaliserar det uppringda partens nummer till +E.164. Den sekundära uppsö kningen använder sedan samma anropande sökutrymme SJCinternational igen (anropar sökutrymmes arv) och +E.164-siffriga strängen matchas antingen av ett +E.164-katalognummer i DN-partitionen eller av ett av PST N- ruttmönstren i partitionen USPSTNnational eller SJCpStnLocal. Förkortade interna och intersite-uppringningsvanor implementeras av översättningarna i ESN- och SJCTO E 164-partitionen. Medan ESN- partitionen är en global partition (tillgänglig för telefoner på alla platser) är SJCTOE16 4-partitionen endast tillgänglig för användare på plats SJC. Detta förutsätter överlappande förlängningsintervall.
Det första steget för att aktivera samtal från till är att se till att+E.164-destinationer dirigeras därefter. Detta kan uppnås genom att lägga till en partition i uppringningsplanen, lägga till +E.164 ruttmönster för alla destinationer till den partitionen, och slutligen lägga till partitionen till alla anropande sökutrymmen som representerar klasser av tjänster som måste kunna nås. Att skapa en dedikerad partition krävs för att möjliggöra skapande av en differentierad klass av tjänster för samtal som härrör från. För att undvika samtalslingor bör sökutrymmet för inkommande samtal på trunken från den lokala gatewayen inte ha åtkomst till partitionen.
Som visas i figur +E.164 routing tillWebex Calling, för att möjliggöra routing från till för en plats med+E.164 DID-intervall +1 221 555 2XXX och platskod 121, måste ett brådskande rutt mönster som matchar detta+E.164-intervall läggas till i partitionen.
Om inget platsspecifikt val av lokal gateway krävs kan du istället för att använda en ruttlista med en lokal ruttgrupp som mål för ruttmönster som pekar på en enda ruttgrupp etableras med den lokala gatewayen som enda medlem och sedan pekar ruttmönstren på en enda ruttlista med den här ruttgruppen som enda post.
För att aktivera förkortad uppringning mellan platser till platsen läggs det nödvändiga ruttmönstret 8121.2XXX till partitionen. För platser som ska övergå till ett uppringningsnormaliseringsmönster 8121.2XXX som normaliserar ESN-uppringning till +E. 164 kan det redan finnas i ESN-partitionen. I så fall verkar 8121.2XXX vara överflödig, men så snart alla DN:er på respektive plats har migrerats över till 8121.2XX X-uppringningsnormaliseringsmönstret kan översättningsmönstret tas bort och sedan möjliggör ruttmönstret 8121.2XXX ESN-uppringning även för användare som endast använder anknytning i det området.
Med dessa uppringningsplanändringar kan samtal till platsen göras inte bara genom att ringa förkortat inter-site och +E.164. Internationell och nationell PSTN-uppringning är också möjlig eftersom dessa uppringningsvanor först normaliseras till +E.164 genom de redan befintliga översättningsmönstren för uppringningsnormalisering och sedan dirigeras till genom att matcha ruttmönstret +E.164 i partitionen.
+E.164-ruttmönstermatchningen på platsens DID-intervall kan etableras medan alla DID fortfarande är på. Den bästa matchningsmönstermatchningsalgoritmen ser till att när ett nummer som är värd är uppringt så matchar +E.164-katalognumret som tillhandahålls på bättre än det jokertecknade +E.164-ruttmönstret som pekar på så att samtalen utvidgas till en linje på och inte skickas till.
uppringningsplan
Varje användare har ett tillägg och/eller ett +E.164-telefonnummer. Tilläggslängden är en fast global inställning: alla tillägg i en distribution har samma längd. Anslutningsuppringning kan användas mellan användare både inom en plats och mellan platser. Förkortad uppr ingning mellan webbplatser (det senare fallet) fungerar bara om det uppringda tillägget är unikt.
Om förkortad uppringning mellan platser mellan platser är ett krav men det finns överlappningar mellan tillägg som tilldelats på olika platser, måste en företagsspecifik numreringsplan skapas genom att föregå tilläggen med en åtkomstkod en webbplatskod. Mer information finns i Preferred Architecture for Cisco Collaboration 15 On-premises Deployments, Designöversikt finns på Ciscos föredragna arkitekturer för samarbete.
Anslutningslängden, uppringningsbeteendet mellan lokaliseringsanordningarna, prefixlängden för uppring ning mellan lokaliseringar och styrsiffran i routingprefixet för uppringning mellan lokaliseringar konfigur eras i inställningarna för samtalstjänsten i:
-
Platsroutningsprefixlängd: Prefixlängd inklusive styrsiffran. K rävs endast om en företagsnummerplan måste upprättas som alternativ förkortad uppring ningsmetod mellan företag.
-
Styrsiffra i routingprefix: Styrsiffra för förkortad uppringnings vana mellan företag. Överlappningar med första siffran på valfri plats och plats för utgående uppringningssiffror bör undvikas. K rävs endast om en företagsnummerplan måste upprättas som alternativ förkortad uppring ningsmetod mellan företag.
-
Intern förlängningslängd: Standardlängd på förlängningar. Kan vara vilket värde som helst mellan två och tio.
När telefonnummeruppringning eller uppringning med betydande företagsnummer (styrkod, platskod, anknytning) krävs från en lokal samtalskontroll till och den lokala samtalskontrollen skickar ett anknytning som uppringnings-id, måste du också ange parametern Maximal okänd anknytningslängd i avsnittet Samtalsdirigering mellan och lokaler för att säkerställa att uppströmssamtal från den lokala samtalskon trollen till kan klassificeras som lokala samtal korrekt. -
Tillåt nummeruppringning mellan platser: Växla för att aktivera/inaktivera anslutningsuppringning mellan platser. Det här alternativet bör endast aktiveras om alla tillägg inom organisationen är unika. Om alternativet är inaktiverat måste företagets betydande nummer (styrkod, webbplatskod, anknytning) eller telefonnummer ringas mellan platser.
De tre första parametrarna används främst för att bygga en uppringningsplan för telefoner för att minimera mellan siffriga timeouts när du använder off-hook-uppringning. Avvikelser från dessa globala inställningar är fortfarande möjliga (Exempel - tillägg med en annan längd kan etableras), men ett varningsmeddelande dyker upp i Control Hub och uppringning från telefoner kan kräva blockering av uppringning för att undvika konflikter inom den förinstallerade uppringningsplanen.
Tabellen Enterprise numrering sexempel visar ett exempel på tre platser där tilläggsområdena för två platser, NYC och RTP, är identiska. Upprättande av ett företags numreringsschema med styrsiffra mellan platser 8, följt av en tresiffrig webbplatskod, och det fyrsiffriga tillägget skapar en icke-överlappande förkortad uppringningsvana mellan webbplatser.
| Webbplatsen | Förlängningsintervall | Webbplatskod | Enterprise-sortiment |
|---|---|---|---|
| NYC | 2XXX | 202 | 8 202 2XXX |
| SFO | 3XXX | 203 | 8 203 3XXX |
| RTP | 2XXX | 204 | 8 204 2XXX |
För att möjliggöra en smidig övergång bör uppsättningen uppringningsvanor för användare före och efter övergången till idealiskt vara densamma. För att förbereda övergången för varje plats måste DID-intervall och förlängningsintervall (eller förkortade uppringningsvanor inom webbplatsen) dokumenteras. Baserat på denna information måste styrsiffran mellan anläggningarna väljas.
Tabellen F asta längdförlängningsintervall visar ett exempel på tre platser och förlängnings intervall med fast längd. Eftersom överlappande uppringningsvanor måste undvikas är det viktigt att se till att den första siffran i intervallet inte matchar styrsiffran för förkortad uppringning mellan platser för alla förlängningsintervall. Om till exempel 8 väljs som styrsiffra för uppringning mellan platser, då kan inget tilläggsområde på någon plats börja med 8. Vanligtvis matchar tilläggen på en viss plats de sista siffrorna i DID: erna som tilldelats den platsen. För att undvika konflikter kan den första siffran i förlängningen ändras. Om till exempel DID i intervallet +1 408 555 8XXX används på en plats, kan istället för att använda 8XXX som förlängningsområde 7XXX användas för tilläggen på den webbplatsen
| Webbplatsen | Förlängningsintervall | Förlängningar | Webbplatskod | Enterprise-sortiment |
|---|---|---|---|---|
| NYC | 2XXX | 2XXX | 202 | 8 202 2XXX |
| SFO | 8XXX | 7XXX | 203 | 8 203 7XXX |
| RTP | 1XX | 11XX | 204 | 8 204 11XX |
Sjusiffriga uppringningssträngar som ringts på en enhet som använder den amerikanska uppringningsplanen överlappar med ett sjusiffrigt mönster för lokal uppringning i den förinstallerade amerikanska uppringningsplanen. För att undvika överlappningar mellan alla uppringningsvanor på nätet och utanför nätet (PSTN) kan en obligatorisk extern åtkomstkod användas på den platsen. Om det befintliga företagsnumreringsschemat och motsvarande förkortade uppringning mellan platser överlappar mönster i den nationella urtavlan, kan under övergången till numreringsschemat för att undvika överlappningar också ändras till en längre eller kortare form. Det enklaste sättet att uppnå detta är att lägga till en extra fyllnadssiffra i numreringsschemat. Det nya längre schemat för uppringning mellan webbplatser behöver bara antas av användare som redan migrerats till. Användare som fortfarande är på kan fortsätta att ringa sju siffror. I det här fallet måste företagets uppringningsplan se till att förkortad sjusiffrig uppringning från Unified CM till omvandlas till antingen +E.164 eller till det förkortade uppringningsformat som används på. Detta måste göras innan du skickar samtalet till den lokala gatewayen.
Den sjusiffriga uppringningen Tabellövergång visar ett exempel på denna omnumrering. I det här exemplet använder förkortad uppringning mellan platser styrsiffra 8 följt av en tvåsiffrig webbplatskod och ett fyrsiffrigt tillägg. För att undvika sjusiffrig förkortad uppringning mellan platser för platser på, kan webbplatskoderna enkelt ändras till tre siffror genom att föregå en godtycklig fyllnadssiffra (8 i exemplet) till de två siffriga webbplatskoderna som används i så att uppringning mellan platser från telefoner använder styrsiffran 8 följt av fyllnadssiffran 8, den gamla tvåsiffriga webbplatskoden och det fyrsiffriga tillägget. Användare på behöver inte komma ihåg nya webbplatskoder; de behöver bara komma ihåg att använda 88 som prefix för uppringning mellan webbplatser istället för 8 på.
| Webbplatsen | Förlängningar | Webbplatskod | Enterprise-sortiment | Webbplatsens ode | Enterprise ange |
| NYC | 2XXX | 22 | 8 22 2XXX | 822 | 8 822 2XXX |
| SFO | 8XXX | 23 | 8 23 7XXX | 823 | 8 823 7XXX |
| RTP | 1XXX | 24 | 8 24 11XX | 824 | 8 824 11XX |
I ett scenario med olika företagsnummerformat aktiverade och om företagsnummer presenteras som information om den uppringande parten för samtal från till (till exempel - Samtal från enheter utan DID), är det viktigt att också implementera en m appning mellan de olika nummerformaten för information om den uppringande parten för att säkerställa att återuppringningen fungerar. Denna mappning kan uppnås genom att använda samtalspartens transformationsmönster på trunken mellan och den lokala gatewayen.
Inspelning
En väldesignad samtalsinspelningslösning kräver noggrann övervägning av flera viktiga designelement för att säkerställa att den överensstämmer med organisatoriska mål, lagkrav och tekniska begränsningar. Två av de mest kritiska besluten handlar om val av leverantör och regionval, som båda kan behöva skräddarsys globalt och åsidosättas på specifika platser, baserat på affärsbehov.
1. Val av leverantör av samtalsinspelning
Att välja lämplig leverantör av samtalsinspelning är grundläggande för att uppfylla affär smålen och säkerställa att funktionerna anpassas i hela organisationen:
-
Ur@@ val av global leverantör: Organisationer utser vanligtvis en primär samtalsinspelningsleverantör på global nivå, vilket säkerställer enhetlighet i funktionsuppsättning, efterlevnad och support på alla platser
-
Platsbaserade åsidosättningar: I scenarier där specifika platser eller regioner har unika affärsbehov eller lagstadgade krav kan det vara nödvändigt att åsidosätta det globala leverantörsvalet och ange alternativa leverantörer för dessa platser. Denna flexibilitet stöder olika efterlevnadsmandat och lokala operativa behov
-
Affärskrav: Valet av leverantör bör styras av en bedömning av företagets drivkrafter såsom regelefterlevnad (exempel - MiFID II, HIPAA), kvalitetssäkring, tvistlösning eller utbildningsbehov
-
Tillgänglighet för funktioner: Leverantörer bör utvärderas utifrån deras förmåga att leverera nödvändiga funktioner, till exempel realtidsövervakning, sök- och uppspelningsfunktioner, kryptering, lagringspolicyer, integration med analysplattformar och stöd för olika samtalstyper (inkommande, utgående, interna).
2. Val av region
Att bestämma regionen där samtalsinspelningar lagras och bearbetas är avgörande för efterlevnad och prestanda:
-
Globalt regionval: Som standard kan organisationer välja en enda region för lagring av samtalsinspelningar för att förenkla hantering och styrning
-
Platsbaserade regionåsidosättningar: När lagar om dataredighet eller företagspolicyer kräver det kan det vara nödvändigt att åsidosätta den globala regioninställningen för specifika platser, så att samtalsinspelningar lagras och behandlas inom de geografiska gränserna som krävs.
-
K@@ rav på datalägenhet: Designen måste ta hänsyn till internationella och lokala dataskyddsbestämmelser (som GDPR, CCPA eller landsspecifika mandat) som kan diktera var och hur samtalsinspelningar behålls.
En annan kritisk aspekt som ska tas upp vid planering och utformning av en samtalsinspel ningslösning för är uppskattningen av lagringsbehov. Noggrann prognos för lagringsbehov är avgörande för att säkerställa att tillräcklig kapacitet finns tillgänglig för att stödja pågående affärs verksamhet, upprätthålla efterlevnad och undvika störningar i tjänsten.
Flera viktiga parametrar bör beaktas vid bestämning av det förväntade lagringsbehovet:
-
Volymen av inspelade samtal: Bedöm det förväntade antalet samtal som kommer att spelas in inom ett visst tidsintervall (t.ex. per dag, vecka eller månad). Detta inkluderar inte bara externa samtal utan även intern kommunikation, om det krävs enligt affärspolicy eller myndighetsmandat
-
Genomsnittlig samtalstid: Beräkna den typiska längden på inspelade samtal, eftersom längre samtal tar mer lagringsutrymme. Variationer i samtalslängd mellan olika avdelningar eller användargrupper bör också beaktas i uppskattningen
-
L@@ agringsperiod: Definiera hur lång tid inspelningar måste behållas, vilket ofta dikteras av organisationens policyer eller externa regler (till exempel branschspecifika efterlevnadsstandarder). Längre lagringsperioder ökar det totala lagringskravet
-
Tillväxtprognoser: Tänk på förväntad tillväxt i samtalsvolymer eller utvidgning av inspelningsomfånget, vilket kan bero på affärsskalning, nya lagkrav eller introduktion av ytterligare användare eller platser.
Genom att noggrant analysera dessa parametrar kan organisationer utveckla en robust lagringsstrategi som säkerställer skalbarhet, kostnadseffektivitet och regelefterlevnad för deras samtalsinspelningslösning. Det är också tillrådligt att regelbundet granska och justera lagringsalloker ingar när användningsmönstren utvecklas över tiden.
Nödsamtal
Kravet att dirigera ett nödsamtal till lämpligt sändningscenter är ett krav för alla samtalstjänster som erbjuder PSTN-tjänst. Med, dirigeringen av nödsamtal är inbyggd i lösningen och inkluderar stöd för alla nationella nödnummer i de länder som stöder. Routningen av ett nödsamtal baseras på den plats som definieras inom och PSTN-åtkomstmetoden för platsen. Nödnumren i är fördefinierade och specifika för det land som användarna och enheterna är distribuerade i.
Det finns två sätt att leverera nödsamtal. Det finns en grundläggande rutttjänst för nödsamtal och en förbättrad rutningstjänst för nödsamtal. Den grundläggande rutttjänsten för nödsamtal använder ett administratörsvalt nummer för att identifiera platsen och samtalsvägen för att nå räddningstjänsten. För grundläggande nödsamtal är samtalsvägen vanligtvis via kundens PSTN-alternativ för den platsen . har också förbättrad ruttning av nödsamtal utformad för distributioner i USA och Kanada som har krav på regelefterlevnad som kräver användning av en rikstäckande leverantör för att leverera nödsamtal till rätt sändningscenter.
Alla kunder bör åtminstone distribuera den grundläggande konfigurationen för nödsamtal. Grundläggande nödsamtal kräver att minst ett kundägt +E.164-nummer tilldelas varje plats som definieras i. För grundläggande nödsamtal, varje plats kommer att definieras av en gatuadress som polis, brand- eller ambulanstjänster skickas till vid nödsituationer. I de flesta fall är huvudnumret för platsen det bästa valet för att representera den fysiska platsen för nödsituationen. Vanligtvis samordnas tilldelningen av adressen till+E.164-numret med P STN-leverantören. Bilderna nedan visar tilldelningen av huvud numret som ska användas som nöduppringningsnummer för Richardson-platsen.
I de flesta situationer är en byggnadsadress tillräcklig för avsändningsadressen för platsen. Men om ytterligare platsinformation behövs för specifika användare eller enheter kan en administratör använda samma process som beskrivs ovan och tilldela dessa enheter till en specifik adress eller en mer exakt plats inuti adressen (som ett golv eller ett rum). Under Användarhantering i tillåter fliken Samtal att ett specifikt nummer kan användas för en användare och deras enheter för att få en specifik avsändningsadress. Följande bilder illustrerar hur ett specifikt nummer kan tilldelas en enhet. Administratören ansvarar för att numret som används av enheten har rätt leveransadress tilldelad den. Adres stilldelningen görs vanligtvis via PSTN-leverantören för den platsen.
För USA-baserade telefoniinstallationer som måste tillhandahålla förbättrade nödsamtal slösningar, använder RedSkys Horizon Mobility integrerad i för ruttning av nödsamtal. När du använder RedSky för samtalsdirigering måste en administratör registrera sig för ett konto via Cisco och konfigurera lämplig information i Samtal -> Serviceinställningar för att aktivera den här funktionen. När RedSky- tjänsten har aktiverats på systemnivå kommer en administratör att aktivera RedSky- tjänsten på varje platsnivå. Aktiveringen av Förbättrade nödsamtal på en plats aktiverar tjänsten för alla enheter som är tilldelade den platsen. Enheter som stöder förbättrat nödsamtal är Cisco MPP-telefoner, Cisco PhoneOS-telefoner och Ciscos.
Det finns två inställningar för att aktivera Förbättrat nödsamtal på en plats. Tillåt RedSky att ta emot information om nätverksanslutning och testsamtal bör användas för att verifiera att RedSky-konfigurationen för enhets- och infrastrukturmappningar är korrekt. Den här inställningen gör det också möjligt att placera testsamtal till 933 för att utföra plats verifiering med RedSkys IVR-system för att läsa upp platsen för den som ringer. Även om detta dokument inte täcker RedSky-konfigurationen för platsspårning, bör en administratör ALLTID testa sin platsupptäckt innan nöd samtal aktiveras för att dirigera till RedSky. När testningen har slutförts och verifierats som korrekt kommer administratören att dirigera samtal till RedSky genom att växla rutten nödsamtal till RedSky. Denna växling riktar alla nödsamtal för platsen till RedSky för leverans till telefonsvararen för platsen.
Inställningarna för förbättrade nödsamtal gäller även för klienter både lokalt och externt. När det är lokalt kan det spåras på samma sätt som skrivbordstelefoner spåras. När den är utanför lokal, användaren kommer att kunna ställa in sin plats dynamiskt direkt i. Mer information om nödsamtal finns i Förbättrat nödsamtal för.
Licensiering
Det finns flera alternativ för att tilldela licenser till användare.
Manuell tilldelning genom
Administratörer tilldelar licenser manuellt till enskilda användare via gränssnittet.
Administratörer kan redigera tjänstelicenser för enskilda användare och tilldela samtalslicenser direkt.
Mallar för automatisk licenstilldelning
Använd mallar för licenstilldelning för att automatiskt tilldela licenser till användare baserat på grupp- eller organisationsinställningar.
Automatisk licensiering kan göras genom katalogsynkronisering eller manuella användaruppdateringar, men användare måste ha ett giltigt +E.164-formaterat telefonnummer och telefonnumren måste finnas på en plats innan användaren tillhandahåller. Om villkoren inte uppfylls (t.ex. ogiltigt telefonnummer format) kommer licenser inte att tilldelas.
Masstilldelning via CSV-mall
Ladda upp en CSV-fil med användarinformation och licenstilldelningar för att lägga till eller ändra flera användare samtidigt.
CSV-import stöder att lägga till upp till 20 000 användare och tilldela licenser, men licenser kräver specifika fält som telefonnummer och tillägg.
API-baserad tilldelning
Använd API:er för att programmera tilldela licenser och hantera användare.
stöder API-operationer för användar- och licenshantering (People, SCIM 2.0 och Licenses API:er), som kan utnyttjas för automatisering av licenstilldelning. Licenser API tillåter samtidig tilldelning av licenser, telefonnummer och tillägg.
| Uppdragsmetod | Fördelar | Nackdelar |
|---|---|---|
| Manuell genom | Enkelt för få användare. Tillåter exakt och detaljerad kontroll över tilldelning av licenser. | Inte skalbar, tidskrävande Benägen för mänskliga fel vid manuell inmatning. |
| Automatiska licensmallar | Skalbar Minskar manuella fel Kan tillämpas på nya och befintliga användare. | Kräver giltiga telefonnummer och platser. Mer komplicerat att sätta upp Kräver också användargrupper per grupp användare med motsvarande licenskrav. |
| Massuppladdning av CSV | Effektiv för stora användaruppsättningar Tillåter samtidig tilldelning av licenser, telefonnummer och tillägg. | Kräver noggrann CSV-formatering Risken för fel om telefonnummer eller tillägg saknas eller är felaktiga. |
| API-baserad tilldelning | Automatiserbar, flexibel. Tillåter samtidig tilldelning av licenser, telefonnummer och tillägg. | Kräver utveckling och API-kunskap. |
Tabellen Användarprovisioneringsalternativ - sammanfattning sammanfattar användarprovisioneringsalternativ och deras fördelar och nackdelar. Den här översikten hjälper dig att välja den bästa licenstilldel ningsmetoden baserat på kundens organisationsstorlek, automatiseringsfunktioner och användarprovisionerings processer och krav.
När det är möjligt rekommenderar Cisco att tilldela samtalslicenser med hjälp av licensmallar. Detta kräver att för varje grupp användare som kräver en unik uppsättning licenser (Exempel - Standard vs. Professionell) en grupp med respektive gruppmedlemskap finns. Som diskuteras i avsnitten Användargrupper kan användargrupper definieras manuellt i eller synkroniseras från en företagskatalog. En kombination av båda metoderna är möjlig.
Användare som tillhör flera grupper får licenser från alla tilldelningar som tillämpas på alla deras grupper. Detta gör det möjligt att använda licensspecifika säkerhetsgrupper i företagskatalogen för att hantera licenstilldelning där den resulterande användarlicenstilldelningen styrs av föreningen av gruppmedlemskap.
Mer information finns i Ställa in automatiska licenstilldelningar i Control Hub och Konfigurera mallar för automatisk licenstilldelning för Webex Calling användare.
Licenskrav
Detta avsnitt omfattar endast relaterade licenser. Andra licenstyper (Exempel - Webex-enhetsregistrering, meddelanden, möten) täcks inte. Som en del av designprocessen måste licenskraven fastställas. Licensantal för följande licenstyper måste beräknas:
-
Standard: antal enskilda användare som kräver standardtelefonfunktioner.
-
Profession ell: antal användare och arbetsytor som kräver avancerade telefon funktioner. Virtuella linjer och gruppröstbrevlåda har rätt till ett förhållande på 1:1 för varje professionell licens. Därför, i sällsynta fall där antalet nödvändiga virtuella linjer eller gruppröstmeddelanden överstiger antalet användare och arbetsytor som kräver avancerade telefon funktioner, ytterligare professionella licenser måste redovisas.
-
Arbetsyta för gemensamt område: antal delade användningsområden eller gemensamma utrymmen som kräver standardsamtalsfunktioner.
-
Kundassistans: antal agenter och handledare som kräver Customer Assist-funktioner. Kundassistenten inkluderar Professional-licensen.
-
Ruttlistanrop: antal obligatoriska molnanslutna PSTN-samtal mellan lokala användare och/eller lokala specialiserade tredjepartsprogram.
-
Attendant Console: antal användare som behöver åtkomst till den skötande konsolklienten.
-
Cisco Calling Plan (Outbound Calling Plan): antal användare som behöver ett PSTN- nummer och/eller utgående PSTN-samtalsåtkomst för Cisco PSTN-tjänsten.
Det finns ingen dedikerad licenstyp för professionella arbetsytor. Professionella arbetsytor använder en Professional-licens.
Enbart arbetsytor med hot-desk erbjuder hotdesking-värdtjänsten och nödsamtal från hotdesk ing-värden och kräver ingen licens. Mer information finns i Lägga till och hantera enheter endast för hot desk.
Om du vill bestämma vilken licenstyp som krävs för varje användare och arbetsyta baserat på funktioner som behövs, se Funktioner tillgängliga efter licenstyp för Webex Calling.
För att skilja mellan funktionalitet som erbjuds av samtalsköer i kombination med den professionella licensen i motsats till kundassistans, se jämförelse av Webex Calling samtal skö och kundassistansfunktioner.
Tillhandahållande av användare
När du etablerar användare i Webex finns det flera alternativ tillgängliga, var och en anpassad till olika organisationsbehov och miljöer:
-
Manuell etablering: Administratörer kan lägga till och hantera enskilda användare direkt inom. Denna metod är enkel men bäst lämpad för små organisationer eller begränsade användar ändringar.
-
Massprovisionering via CSV: För större användarbaser kan administratörer importera och uppdatera användare i bulk genom att ladda upp CSV-filer till. Detta möjliggör effektiv hantering av upp till tusentals användare samtidigt.
-
Alternativ för katalogsynkronisering:
Directory Connector: Detta är ett automatiskt synkroniseringsverktyg som används i Microsoft Active Directory miljöer. Det synkroniserar användarkonton, grupper och attribut på schemalagd basis (timme, dag eller vecka). Den stöder inställningar för flera domäner och flera skogar Active Directory och kan synkronisera profilbilder och rumsobjekt.
Guide@@ appen Entra ID (Azure AD): Den här metoden är utformad för organisationer som använder Microsoft Entra ID (Azure AD) och ger automatisk synkronisering i nära realtid av användar konton och attribut direkt från Entra ID till. Det hanteras helt internt och kräver minimal installation.
SCIM 2.0-program: För miljöer utanför Microsoft eller andra identitetsleverantörer som Okta eller Duo möjliggör SCIM-baserade synkroniseringsappar automatisk användarprovisionering och avprovisionering med attributmappning och gruppsynkronisering.
-
Unified CManvändarsynkronisering: Det här alternativet gör det möjligt att skapa användarkonton baserat på befintliga slutanvändare genom att synkronisera från till. Detta kräver att Cloud Connected UC (CCUC) körs på lokala kluster. Det rekommenderas dock generellt att synkronisera användare från en centraliserad molnkatalog som Entra ID snarare än direkt från.
-
API-provisionering: Offentliga API:er (People, SCIM 2.0) kan användas för att tillhandahålla användare. Den största fördelen med att använda API:er är möjligheten att integrera användarprovisionering med andra företagssystem.
Den här översikten och tabellen återspeglar de viktigaste tilldelningsalternativen för användare, deras fördelar och begränsningar för att hjälpa dig att välja den bästa metoden för din organisations behov.Tabell 6. Tillhandahållande av användare för Tilldelningsmetod Beskrivning Fördelar Nackdelar Manuell Skapa/hantera användare individuellt i Enkelt för få användare, ingen infrastruktur behövs Inte skalbar; tidskrävande för många användare Bulk (CSV-fil) Importera/uppdatera användare i bulk via CSV i Effektiv för grupper; ingen kodning krävs Manuell CSV-förberedelse; mindre dynamisk Människor och SCIM 2.0 API Programmatisk användarhantering via Webex API:er Flexibel; stöder automatisering och integration Kräver utveckling och infrastruktur Katalogsynkronisering Automatisk synkronisering från AD, Entra ID, SCIM-appar, Unified CM Automatiserar livscykeln; stöder filtrering och kartläggning Inställningskomplexitet: vissa av alternativen har begränsade funktioner eller kräver infrastruktur
Användargrupper
Användargruppshantering i gör det möjligt för administratörer att organisera användare i grupper för effektiv masshantering av licenser, inställningar, och resurser. Grupper hjälper till att effektivisera administrationen genom att tillämpa principer, licenser och inställningsmallar för flera användare samtidigt, i stället för att hantera användare individuellt.
Hantering av användargrupper erbjuder flera fördelar inklusive:
-
Förenklad administration: Hantera licenser, inställningar och policyer för flera användare samtidigt.
-
Kon sekvens: Tillämpa enhetliga inställningar och licenser för användare i samma grupp.
-
Skalbarhet: Stöder upp till 250 000 medlemmar per grupp.
-
Integrering: Synkronisera grupper från Microsoft Entra ID (Azure AD) eller Active Directory för automatiserad användar- och grupphantering.
-
Flexi bilitet: Skapa lokala grupper eller synkronisera säkerhetsgrupper; hantera grupp medlemskap manuellt eller via CSV-filer.
-
Resursallokering: Kontrollera åtkomst till inbäddade appar och tjänster baserat på gruppmedlemskap.
De viktigaste användningsfallen för användargrupper vid etablering är:
-
Licens tilldelningar: Tilldela licenser till grupper för att automatiskt tillhandahålla tjänster som samtal, möten, meddelanden eller hybridtjänster till gruppmedlemmar.
-
Inställningsmallar: Använd samlingar av tjänsteinställningar (t.ex. meddelanden, möte, samtal) på grupper för enhetlig användarupplevelse.
-
Han@@ tering av massanvändare: Lägg till eller ta bort användare i bulk via CSV-filer eller katalog synkronisering.
-
Automatisering och integration: Använd API:er eller katalogsynkronisering för automatiserad livscykelhantering för användare och grupper.
Följande tabell sammanfattar de olika alternativen för att hantera användargrupper och grupphan tering i.
| Alternativ | Beskrivning | Fördelar | Nackdelar |
|---|---|---|---|
| gruppprovisionering (grupper) | Skapa och hantera grupper direkt i. Lägg till/ta bort medlemmar manuellt eller via CSV. | Full kontroll över gruppmedlemskap Omedelbar tillämpning av licenser och mallar Enkelt att skapa och redigera grupper |
Manuella uppdateringar krävs Risk för fel vid manuella CSV-uppladdningar Ingen automatisk synkronisering med externa kataloger |
| Synkroniserade grupper från Entra ID (Azure AD) eller Active Directory | Synkronisera säkerhetsgrupper och medlemskap automatiskt från externa katalog tjänster. | Automatiserad synkronisering minskar manuellt arbete Säkerställer överensstämmelse med företagskatalogen Stöder stora organisationer |
Det går inte att redigera gruppmedlemskap i Synkroniseringsfördröjning upp till 12 timmar Kapslade grupper kräver manuell markering |
| Grupper och SCIM 2.0 API (grupper) | Använd grupper eller SCIM 2.0 API för programmatisk grupp- och medlemshantering | Automation och integration med andra system Skalbar för stora eller komplexa miljöer |
Kräver utvecklingsinsats Komplexitet beror på API-användning |
Medan synkroniserade grupper säkerställer konsistens och erbjuder en enda administrationspunkt, är en hybridmetod som kombinerar synkroniserade grupper och grupper (antingen hanterade i kontrollhubben eller via API:er) möjlig. Så, till exempel grupper för licenstilldelning kan vara synkroniserade grupper och en separat uppsättning grupper kan användas för att tilldela användar- och samtalsmallar.
Detta omfattande tillvägagångssätt för hantering av användargrupper gör det möjligt för organisationer att effektivt hantera användarlicenser, inställningar, och policyer, vilket säkerställer konsekventa och skalbara samarbetsupplevelser.
Rekommenderat tillvägagångssätt vid migrering från till
Den primära datakällan för användare på är databasen, som innehåller slutanvändarinformation. i alla fall, är vanligtvis inte den auktoritativa källan för hantering av användaridentitet och ännu viktigare kommer att stängas av i slutet av övergången och utesluts därför som långsiktig auktoritativ källa för identitetsinformation.
Cisco rekommenderar att du använder en centraliserad molnkatalog som Microsoft Entra ID (Azure AD) som enda sanningskälla för användaridentiteter. Synkronisera användare från Entra ID för att säkerställa konsistens, förenklar hantering och stöder funktioner för enkel inloggning (SSO).
För att säkerställa att alla användare på också finns i Entra ID bör organisationer kontrollera att användarkontona i motsvarar konton i Entra ID. Detta kan göras genom att exportera användarlistor från och jämföra dem med användarlistor för Entra ID.
Sammanfattningsvis är den rekommenderade etableringsmetoden att synkronisera användare från Microsoft Entra ID (Azure AD) till Webex med hjälp av guiden Azure AD eller SCIM-appar. Manuell och CSV-bulkprovisionering finns som kompletterande metoder, men är mindre skalbar och mer felbenägen för stora organisationer. Att säkerställa att Entra ID är den auktoritativa källan och att alla användare finns i Entra ID är avgörande för en lyckad migrering och konsekvent användar upplevelse över och miljöer.
Övergången från en lokal katalogtjänst, till exempelActive Directory, till en molnkatalogtjänst, som Entra ID (Azure ID), är oberoende av anropsövergången. Cisco rekommenderar att övergången till en molnkatalogtjänst avslutas innan samtalsöver gången påbörjas.
Designa användargrupper
Efter att ha övergått företagskatalogen från lokalt till molnet samlar du in de användargrupper som krävs som drivs av licens- och funktion smallkrav. För varje gruppdokument:
-
Gruppnamn: unikt namn på gruppen.
-
Licenser: licenser som ska tilldelas denna grupp (om sådana finns) och omfattning (bör licenser tilldelas befintliga användare eller endast till nya användare)
-
Inställningsmallar: Webex App- och Användarsamtalsmallar.
-
Katalogsynkronisering: Synkroniseras den här gruppen från företagskatalogen eller är detta en lokal Webex-grupp etablerad i Control Hub eller via ett API.
-
Beskrivning: hur kommer den här gruppen att användas och vilka användare som ska vara medlemmar i den här gruppen
Dessa uppgifter kommer att användas senare under implementeringsfasen för att skapa lokala grupper eller grupper i företagskatalogen och hantera användarnas gruppmedlemskap.
Enkel inloggning (SSO)
Cisco rekommenderar användning av SSO för användarautentisering. Att använda SSO har några övertygande fördelar inklusive:
-
Förenklad användarautentisering: Användare kan logga in en gång med sina företag suppgifter (t.ex. från Azure ID) för att komma åt och andra integrerade program, vilket eliminerar behovet av flera lösenord och minskar inloggningsuppmaningarna. Detta ökar säkerheten genom att säkerställa att företagslösenord aldrig lagras eller överförs till efter autentisering.
-
Förenklad användarhantering: Automatiserar skapande, uppdateringar och in aktivering av användarkonton baserat på ändringar i företagskatalogen, vilket minskar administrativa kostnader och säkerställer att endast behöriga användare har åtkomst.
-
Förbättrad säkerhet: SS O minskar lösenordsutmattning och risken för lösenordsrelaterade överträdelser genom att centralisera autentisering via betrodda identitetsleverantörer (IDP).
-
Enkel integration av multifaktorautentisering (MFA): MFA kan enkelt stödjas antingen genom en Identity Access Management- lösning som Cisco Duo eller genom MF A-stöd för IdP.
Det finns flera alternativ för att implementera SSO för tjänster:
-
SAML 2.0-baserad SSO: Det primära protokollet som stöds för SSO integration, vilket möjliggör säkert utbyte av autentiseringsinformation mellan Id P och tjänsteleverantören.
-
OpenID connect (OIDC): Stöds som ett alternativt modernt autentiseringsprotokoll för SSO-integration.
-
Webex-identitet: Stö ds även som alternativ för identitetsleverantör.
SSO konfigureras och hanteras centralt genom, vilket kräver utbyte av metadata mellan och den valda IdP.
Efter konfigurationen kan SSO testas inom innan aktivering för att säkerställa korrekt installation.
Cisco stöder integration med flera testade och vanliga IDP och IAM (Identi ty Management System), inklusive men inte begränsat till:
-
Cisco Duo
-
Okta
-
Microsoft Active DirectoryFederationstjänster (ADFS)
-
Microsoft Azure
-
Ping Federate
-
OpenAM
-
F5 BIG-IP.
Dessa IDP överensstämmer med SAML 2.0- eller OpenID Connect-standarderna och har validerats för kompatibilitet med Ciscos samarbetslösningar.
Stöd för flera IdP
gör det möjligt för organisationer att konfigurera SSO med flera IDP för att tillgodose komplexa IT- miljöer som fusioner, förvärv eller decentraliserade IT-avdelningar där olika grupper använder olika IDP. Stöd för flera IdP kan antingen implementeras med funktionen Multi ple IdP i eller genom integration av ett företags-IAM-system som Cisco Duo.
Stödet för flera identitetsleverantörer (IdP) hanterar flera viktiga användningsfall där organisationer kräver flexibel och säker autentisering i olika IT-miljöer:
1. Fusioner och förvärv
När företag går samman eller förvärvar andra har de ofta separata IT-infrastrukturer och distinkta IDP som inte kan federera. Stöd för flera IdP gör det möjligt för användare från båda organisationerna att autentisera och samarbeta säkert utan att behöva förena sina identitetssystem omedelbart.
2. Flera oberoende IT-avdelningar
Stora organisationer eller statliga institutioner kan ha flera oberoende IT-avdelningar, var och en hanterar sin egen IdP. Dess flera IdP-funktion gör det möjligt för dessa avdelningar att upprätthålla sina egna autentiserings system samtidigt som användarna kan komma åt sömlöst.
3. Olika användargrupper eller domäner
Organisationer med olika användargrupper (t.ex. anställda kontra entreprenörer) eller flera e-post domäner kan konfigurera routningsregler för att dirigera autentiseringsbegäranden till lämplig IdP baserat på domän- eller gruppmedlemskap. Detta stöder differentierade åtkomstpolicyer och säkerhet skontroller.
4. Stöd för olika autentiseringsprotokoll
stöder IDP för SAML och OpenID Connect (OIDC), vilket gör det möjligt för organisationer att integrera olika typer av identitetsleverantörer enligt deras befintliga infrastruktur och säkerhetskrav.
5. Förbättrad säkerhet och efterlevnad
Genom att aktivera flera IDP kan organisationer implementera starkare autentiseringsmekanismer, inklusive multifaktorautentisering (MFA) genom integrationer som Duo, och genomdriva konsekventa säkerhetspolicyer för olika användarbaser.
6. Förenklad användarupplevelse
Användare kan autentisera med sina befintliga autentiseringsuppgifter från sina respektive IDP, vilket ger en enhetlig inloggningsupplevelse trots den underliggande komplexiteten hos flera identitetssystem.
Stöd för flera IdP ger flexibilitet, men det kräver noggrann samordning mellan säkerhets- och identitetsteam för att upprätthålla konsekventa säkerhetspolicyer och undvika potentiella sårbarheter.
Duo MFA med SSO för
Duo Access Gateway (DAG) kan autentisera användare med befintliga lokala eller molnbaserade kataloger som Active Directory (AD) och OpenLDAP. Det stöder också integration med andra identitetsleverantörer som Microsoft ADFS, Microsoft Azure, Okta, OneLogin, CAS och Shibboleth. Denna flexibilitet gör det möjligt för organisationer att använda sin nuvarande katalog infrastruktur för Webex SSO med Duo MFA.
Duo fungerar som ett starkt autentiseringslager ovanpå den primära katalogautentiseringen. Den fungerar som en identitetsleverantör (IdP) som använder SAML 2.0 för att genomdriva tvåfaktorsautentisering (2FA) innan åtkomst beviljas. Duo utvärderar användar-, enhets- och nätverkskontext mot konfigurerbara policyer för att tillåta eller neka åtkomst, vilket förbättrar säkerheten utöver bara användarnamn och lösenord. Duo tillhandahåller också flexibla policykontroller, som att kräva MFA vid varje inloggning för vissa appar och mindre ofta för andra.
Fördelarna med Cisco Duo inkluderar:
-
Förbättrad säkerhet: Lä gger till phishing-resistent MFA för att skydda åtkomst, vilket minskar risken för komprometterade lösenord.
-
Flexibla policyer: Tillåter detaljerad kontroll över autentiseringskrav per program eller användargrupp.
-
Integration med befintliga kataloger: Stö der lokal AD, OpenLDAP, moln kataloger och olika SSO-leverantörer, vilket minimerar infrastrukturförändringar.
-
Användarvänlighet: Stö der Single Sign-On (SSO) för att minska lösenordsutmattning genom att göra det möjligt för användare att logga in en gång och få tillgång till flera resurser på ett säkert sätt.
-
Betrodda slutpunkter: Stöder enhetsförtroende för klienter på Windows och macOS, vilket förbättrar säkerhetsställningen.
-
Självbetjäningsregistrering: Inbyggd registrering och duo-prompt förbättrar användarupplevelsen under MFA-installationen.
Duo MFA med SSO för utnyttjar befintliga kataloger som Active Directory och OpenLDAP, eller molnidentitet sleverantörer, för att autentisera användare. Duos roll är att tillhandahålla en stark, policydriven andra autentiserings faktor integrerad genom SAML 2.0, vilket förbättrar säkerheten samtidigt som användarvänligheten upprätthålls genom SSO. Fördelarna inkluderar förbättrad säkerhetsställning, flexibel policy tillämpning, sömlös integration och en bättre användarupplevelse.
Cisco rekommenderar att implementera SSO för användare. För förbättrad säkerhet rekommenderas integrering med Cisco Duo.
Enterprise IAM- och SSO-strategin bör implementeras innan övergången från till påbörjas.
Funktioner
har ett komplett komplement av kärnfunktioner som ingår i tjänsten. Detta inkluderar många samtalsfunktioner i företagsklass som har funnits i många år. Du kanske inte ser 100% paritet mellan funktioner och funktioner, men som du kan se i figuren nedan är de viktigaste samtalsfunktionerna tillgängliga i.
Förutom de många användarfunktionerna, har kärnsystemfunktioner som ingår i plattformen. Dessa inkluderar funktioner som automatiska skötare, samtalsköer, samtalspark, etc. Du kan se alla tillgängliga kärnsystem funktioner under Service → Ring →Funktioner som visas i figur Webex Callingkärn funktioner.
Automatisk skötare
Auto Attendant möjliggör 24/7 automatisering av hantering av inkommande samtal, vilket möjliggör effektiv samtalshantering utan att en person behöver svara på varje samtal.
Den automatiska mottagaren svarar på inkommande samtal och ger den som ringer en meny med alternativ för vart de vill dirigera sitt samtal. Detta kan vara till en person, en röstbrevlåda eller en samtalstjänst (t.ex. Samtalskö). Den som ringer använder telefonens knappsats för att ange numret från menyn för automatisk sköt sel.
Auto Attendant stöder följande nyckelfunktioner:
-
Affärs- och eftertidscheman
-
Semesterschema
-
Alternativet för uppringningsmeny för att rikta dina kunder dit de behöver gå
-
Anpassa hälsningar
-
Alternativ för att ringa efter namn
-
Alternativ för vidarekoppling av samtal
-
Control Hub-analys och rapporter.
Mer information finns i Hantera automatiska telefonsvar are.
Ring Park
Call park ger användarna möjlighet att enkelt sätta ett samtal i väntelä ge så att en annan användare enkelt kan hämta när de är tillgängliga för att ta det. Det frigör också användaren som svarade på det ursprungliga samtalet för att ringa eller ta emot andra samtal medan samtalet är parkerat.
Det finns två typer av samtalsparker tillgängliga i:
-
Call park direct - gör det möjligt för alla användare att parkera ett samtal till en annan användares anslutning eller till en samtalspark-förlängning, enligt definitionen av administratören
-
Samtalsparkgrupp - gör det möjligt för en definierad grupp användare att automatiskt parkera samtal mot tillgängliga parkeringsdestinationer som definierats för gruppen. Dessa destinationer kan vara gruppmedlemmarnas tillägg eller samtalsparktillägg.
Baserat på konfiguration och parker ingstyp kan användare hämta samtal genom att <extension of parked call>ringa *88+>, trycka på linjeknappen som är kopplad till samtalspar kens förlängning eller använda en funktionsknapp på sin IP-telefon.
Ett återkallningsalternativ är tillgängligt för att återkalla ett parkerat samtal efter en viss period till användaren som parkerade samtalet eller till en alternativ användare.
Mer information finns i Hantera samtalsparkering i Control Hub.
Upphämtning av samtal
Samtalsupptagning gör det möjligt för en administratör att definiera en grupp användare (medlemmar) som kan svara på ett samtal till en annan medlems telefon. Detta ger en användare möjlighet att svara på samtal när deras lagkamrater är upptagna och inte kan svara på ett inkommande samtal.
Användarna i en grupp måste vara på samma plats.
Användare kan använda antingen skrivbordstelefonen eller deras skrivbordstelefon för att hämta ett samtal.
-
:
-
Stöder visuella och ljudmeddelanden
-
Meddelande om inkommande samtal
-
FAC-baserad (ring *98) eller avisering av samtalsupphämtning
-
Meddelanden om upphämtning av samtal för multiline.
-
-
Skrivbordstelefoner:
-
Meddelande om inkommande samtal
-
Ljudklockor och visuell avisering via handenhetens LED. 6821 stöder endast ljudklockor
-
När meddelandetypen är vald i är inte ingen
-
-
Meddelanden om upphämtning av samtal endast för primära linjer.
-
Mer information finns i Konfigurera samtalsupphämtnings grupp.
Samtalskö
inkluderar röstsamtalsköer som en del av sina kärnfunktioner och alla användare med en Professional-licens kan vara en del av en samtalskö, agent eller handledare. Denna funktion gör det möjligt för användare att effektivt interagera med kunder. Samtalsköer stöder en delmängd av några av callcen ter-kärnfunktionerna som röstköer, återuppringning, skicklighet eller prioritetsdirigering, hantering av agentköer, analys, rapportering, etc.
Ciscos call for Microsoft Teams-integration gör det möjligt för agenter att komma åt samtalskösamtal och funktioner direkt från sin Microsoft Teams-klient.
Samtalsköer stöder följande nyckelfunktioner:
-
Hälsningar och meddelanden (välkommen, tröst, viskning, etc)
-
Håll musik
-
Återuppringning
-
Policyer för köruttning (nattservice, helgdagar, vidarebefordran)
-
Inloggning/utloggning av agentkö
-
Hantering av agentköstatus
-
eller Desk Telefonsupport
-
Handledare anropar, tränar, pråmar eller tar över genom Feature Access Codes (FACs)
-
(administratörsåtkomst) för:
-
köhantering
-
Agent- och köanalys och rapportering
-
Kö-, agent- och handledarhantering.
-
Mer information finns i Konfigurera samtalsk ö.
har en tilläggsfunktion för kundassistans som ger ytterligare samtalsköfunktioner och ger agenter och handledare en bättre användarupplevelse inom. För en jämförelse av funktionerna Samtalskö och Kundassistans, se Jämfö Webex Callingrelse av samtalskö och kundassistans funktioner.
Jaktgrupp
Hunt Groups möjliggör dirigering av inkommande samtal till en specifik grupp av användare genom ett förutbestämt samtalsrutningsmönster. Detta säkerställer att samtal besvaras av rätt grupp användare eller skickas till en röstbrevlåda för uppföljning.
En stor skillnad mellan jaktgrupper och samtalsköer är att samtal inte köas i en jaktgrupp, så om inga användare i Hunt Group är tillgängliga för att svara på samtalet kommer det att kopplas bort, skickas till röstbrevlådan eller vidarebefordras till ett annat nummer (användare eller tjänst).
Mer information finns i Hantera jaktgrupper i Control Hub.
Driftlägen
Funktionen Operating Modes gör det möjligt för företag att effektivt dirigera samtal till olika destinationer (användare, röstbrevlåda, samtalstjänster som en samtalskö). Var och när ett samtal dirigeras är baserat på ett schema för tid på dagen och veckodag och alla användare kan behörighet att hantera dessa lägen (scheman) för att styra ändringar i samtalsdirigeringen.
Som ett exempel kan samtal till en samtalskö dirigeras till en annan samtalskö med agenter i en annan tidszon för att svara på samtal efter öppettider, under kontorstid dirigeras till lokala agenter, och under helgdagar dirigeras till röstbrevlådan för upp följning efter att agenter återvänt till kontoret.
En auktoriserad användare kan växla mellan dessa olika vidarekopplingsscenarier (lägen) om de behöver ändra var inkommande samtal dirigeras under en viss period. Dessa användare kan hantera lägena via sina 6800/7800/8800 MPP-telefoner, 9800-telefoner eller i användarnavet i Hantera lägen.
Mer information finns i Samtal sdirigering baserat på driftlägen i Webex Calling.
Personsökningsgrupp
Personsökningsgrupper tillåter användare att ringa ett enkelriktat samtal för att skicka ett ljudmeddelande till en grupp användare. Varje grupp kan innehålla upp till 75 målanvändare och/eller arbetsytor som nås genom att ringa ett fördefini erat nummer eller anknytning.
När en användare anropar en personsökningsgrupp görs ett samtidigt samtal till alla tilldelade mål i gruppen, vid vilken tidpunkt den som ringer kan tala sina meddelanden och lägga på när de är färdiga.
Mer information finns i Konfigurera en personsökningsgrupp i Control Hub.
Inspelningar
stöder inspelning av samtal som gjorts eller tagits emot av en användare. Detta kan krävas för kvalitets-, säkerhets-, säkerhets- eller utbildningsbehov. Som standard spelas samtal in, men andra tredjepartsinspelningsleverantörer kan också användas om andra inspel ningsfunktioner eller efterlevnad och lagkrav krävs.
När du använder som inspelningsplattform hanteras alla inspelade samtal inom. Fullständiga administratörer med rollen Compliance officer kan spela och ladda ner inspelningarna. Utan rollen Compliance officer kan administratören bara ta bort inspelningarna.
Mer information om den här funktionen och en lista över inspelningar från tredje part finns i Hantera samtalsin spelning för Webex Calling.
Räckvidd för enstaka nummer
Räckvidd med ett enda nummer tillåter samtal till en användares telefonnummer för att ringa flera enheter. Detta kan inkludera andra skrivbordstelefoner såväl som mobiltelefoner. Samtal kan också göras från dessa enheter och användare kan trycka och dra samtal mellan dem.
Mer information om den här funktionen och hur en administratör konfigurerar den i finns i Konfigurera enstaka nummerräckvidd (kontor var som helst).
Mer information om hur en användare kan hantera och konfigurera den här funktionen för sig själv i Webex User Hub (portalen) finns i Konfigurera enstaka nummer räckvidd (kontor var som helst).
Röstbrevlådegrupp
Röstbrevlådegrupper tillåter en delad röstbrevlåda som kan tilldelas en användare eller samtalsroutningsfunktion. Några av anledningarna till att en röstbrevlådegrupp kan krävas är:
-
Allmän röstbrevlåda för en avdelning eller arbetsgrupp
-
Lägg till röstbrevlådealternativ till en automatisk skötare eller jaktgrupp
-
Så här skickar du överströmningssamtal från en samtalskö
-
Användare som bara behöver en röstbrevlåda.
Mer information finns i Hantera en delad röstbrevlåda och inkommande fax box för. Webex Calling
Attendant Console visas på sidan Samtalsfunktioner i Webex, men det är en tilläggsfunktion som kräver köp av den medföljande konsol licensen för att använda.
Mer information finns i Komma igång med Attendant Console.
Information om alla funktioner, inklusive vissa tilläggsfunktioner, finns i Funktioner tillgängliga efter licenstyp för Webex Calling.
Implementera
Nätverksberedskap
Det första steget i övergången till är att säkerställa tillförlitlig och säker internetanslutning mellan det lokala nätverket och molnet.
Eftersom de flesta organisationer ansluter till internet via en eller flera brandväggar eller säkerhetsenheter är det viktigt att validera att de nödvändiga trafikflödena stöds.
Nätverks- och säkerhetsadministratörer måste förstå dessa flöden i termer av:
-
Riktning (inkommande vs utgående)
-
Protokol l (Exempel - SIP TLS, SRTP, HTTPS)
-
IP-adressintervall som används av tjänster
-
Portnummer som måste öppnas eller tillåtas.
Detta säkerställer att företagets brandväggar, NAT-enheter och annan nätverksinfrastruktur är korrekt konfigurerade för att tillgodose trafik samtidigt som företagets säkerhetsprinciper upprätthålls.
För information om nödvändiga flöden inklusive IP-adress, portar, och protokoll, se Portreferensinformation för Webex Calling. Använd den här informationen för att konfigurera brandväggen, proxyer och annan nätverksinfrastruktur i den befintliga distributionen för att aktivera nätverksflöden.
Decentraliserat internetutbrott från varje filial eller webbplats är det rekommenderade tillvägagångssättet för molnsamarbetstjänster som t.ex. Genom att tillåta trafik att avsluta lokalt, denna modell:
-
Minskar returfördröjning och jitter, vilket förbättrar den totala samtalskvaliteten
-
Skalas effektivt när fler användare och webbplatser övergår till
-
Fungerar sömlöst med SD-WAN, som dynamiskt kan dirigera sessioner till närmaste molningångspunkt för optimal prestanda
- Gör det möjligt att spåra användarens plats baserat på deras offentliga IP-adress vilket hjälper till med analys av medievägar och felsökning.
Dessutom måste organisationer säkerställa tillräcklig internetbandbredd på varje webbplats. Bandbredden bör dimensioneras baserat på det förväntade antalet samtidiga samtal, den valda codec (t.ex. Opus eller G.711), plus overhead för signalering, återsändningar och tillväxt. Detta överensstämmer med förberedelse fasen i PPDIO-livscykeln och skapar en solid grund för migrering.
Inledande installation
Det första installationsunderavsnittet inom implementeringsfasen för distribution är grundläggande för att skapa en välstrukturerad och hanterbar molnsamtalsmiljö. Detta steg omfattar viktiga uppgifter som att konfigurera organisationen, anskaffa och tilldela licenser och verifiera och göra anspråk på företagets domäner för att säkerställa korrekt användarhantering och säkerhet. Dessutom innehåller den provision eringslicensmallar för att automatisera tilldelningar av användarlicenser, konfigurera Single Sign-On (SSO) för att effektivisera användarautentisering och förbättra säkerheten samt justera service- och klientinställningar så att de överensstämmer med organisationens principer och användarbehov. Genom att slutföra dessa initiala installation saktiviteter säkerställs att miljön är korrekt konfigurerad för skalbarhet, säkerhet och sömlös användarupplevelse, vilket skapar förutsättningar för efterföljande driftsättning och driftsfaser.
Domänverifiering
För att kunna identifiera användare som är registrerade med ditt företags e-postdomäner är det viktigt att verifiera dina domäner. Utan domänverifiering kommer användare att tilldelas en konsumentorganisation, vilket komplicerar användarhanteringen för ditt företag. Domänverifiering är ett obligatoriskt steg som gör det möjligt för din organisation att göra anspråk på och hantera dessa användare effektivt.
Se till att alla domäner som är kopplade till dina användares e-postadresser verifieras. Dom änverifiering är inte exklusiv; samma domän kan verifieras i flera organisationer.
Mer information om hur du hanterar domäner finns i Hantera dina domäner.
Gör anspråk på (konvertera) befintliga användare
När du har verifierat dina domäner kan du fortsätta att göra anspråk på användare som har registrerat sig för att använda företagets e-postdomäner i din organisation. Denna process konsoliderar alla användare under ett enda organisatoriskt paraply, vilket möjliggör centraliserad hantering och strömlinjeformad administration. Genom att göra anspråk på dessa användare säkerställer du att ditt företag har full kontroll över användarkonton, så att du kan tilldela lämpliga licenser, konfigurera tjänster och tillhandahålla nödvändig support effektivt. Denna enhet liga hanteringsstrategi förbättrar säkerheten, förenklar användarprovisionering och säkerställer konsekvent åtkomst till tjänster i hela organisationen. Att hävda användare hindrar dem också från att hanteras i externa organisationer eller konsumentorganisationer, vilket upprätthåller organisationens integritet och kontroll över samarbetsresurser.
Mer information om hur du gör anspråk på användare finns i Gör anspråk på användare till din organisation (konvertera) användare.
Konfigurera och testa katalogsynkronisering
Om du vill aktivera sömlös användar- och grupphantering kan du synkronisera användare och grupper från företagskatalogen antingen Microsoft Entra ID (tidigare Azure AD) eller Microsoft Active Directory (AD) till. Denna process säkerställer att användaridentiteter och gruppmedlemskap upprätthålls konsekvent i hela din miljö.
För organisationer som implementerar stegvisa distributioner är det viktigt att kontrollera och begränsa omfattningen av synkronisering under de första utrullningarna. Detta minimerar risken för oavsiktliga förändringar och möjliggör riktad testning före bredare antagande.
Den mest effektiva metoden för att filtrera vilka användare som synkroniseras är att utnyttja kataloggruppsmedlemskap:
| 1 |
Skapa en dedikerad synkroniseringsgrupp: I din företagskatalog (Microsoft Entra ID eller AD) skapar du en säkerhetsgrupp specifikt för synkronisering (till exempel synkroniseringsgrupp). |
| 2 |
Fyll i gruppen med målanvändare: Lägg bara till de användare som du vill synkronisera (till exempel en testgrupp under pilotfasen) till den här gruppen. Detta gör att du kan kontrollera vem som ingår i synkroniseringsprocessen. |
| 3 |
Konfigurera synkroniseringsavtalet med gruppbaserad filtrering: När du konfigurerar synkroniseringsavtalet i Directory Connector eller Entra ID-provisionering konfigurerar du omfattningen så att den endast omfattar användare som är medlemmar i den angivna gruppen.
|
| 4 |
Expandera gruppen efter behov: När du går vidare till bredare distributionsfaser lägger du helt enkelt till ytterligare användare eller grupper i synkroniseringsgruppen. Synkroniseringsomfång et utvidgas automatiskt till att omfatta dessa användare, vilket möjliggör kontrollerad och gradvis utrullning. Exempel på implementeringssteg:
Referenser: Synkronisera användare av Entra ID till Control Hub |
Konfigurera och testa Single Sign-On (SSO)
Single Sign-On (SSO) förbättrar säkerheten och förenklar användaråtkomst genom att låta användare autentisera en gång med sina företagsuppgifter och få sömlös åtkomst till. stöder SSO-integration med SAML 2.0-kompatibla IDP:er, inklusive Microsoft Entra ID (tidigare Azure AD), Active Directory (AD) federerade lösningar och olika tredjeparts-IDP.
Vid denna tidpunkt bör den designade SSO-installationen implementeras och testas.
Referenser:
Integrering av enkel inloggning i kontrollhubben
konfigurera enkel inloggning för webex-administration
Anskaffa, tillhandahålla och verifiera licenser
Som en del av den första installationen för är det viktigt att anskaffa, tillhandahålla och verifiera lämpliga licenser för att aktivera och hantera tjänster effektivt. Upphandlingsprocessen innebär att du väljer licen styper baserat på användarroller och arbetsbelastningar, till exempel Professional-, Standard- och Workspace- licenser. Licenser genereras och tillhandahålls via Ciscos mjukvaruplattformar eller genom partners. Efter upphandling och tillhandahållande måste korrekta licensantal verifieras i. Denna process säkerställer att organisationen har rätt licenser aktiverade och redo att användas i distributionen.
Som en del av den första licensinställningen i är det viktigt att konfigurera organisationsbaserad automatisk licensiering för att effektivisera tilldelningen av licenser för nya användare. Med den här inställningen kan licenser beviljas automatiskt när användare läggs till i organisationen, vilket eliminerar behovet av manuell licenstill delning. När du konfigurerar automatisk licensiering på organisationsnivå väljer du de tjänster som ska tilldelas och definierar omfattningen, till exempel att endast tillämpa licenser på framtida användare eller inkludera befintliga användare.
Om distributionsplanen innebär att du använder automatisk licensiering på gruppnivå i stället kan du välja att inte tilldela licenser på organisationsnivå för att undvika konflikter eller dubbla licenstilldelningar. Med automatisk licensiering på gruppnivå tilldelas licenser baserat på gruppmedlemskap. Användare i flera grupper får licenser från alla tillämpliga grupptilldelningar.
Gruppbaserad licenstilldelningskonfiguration måste utföras efter att katalogsynkroniseringen har slutförts så att synkroniserade grupper finns och kan användas för tilldelning av licenser.
I synnerhet kräver automatisk tilldelning av licenser ytterligare information om etablering, till exempel användarplats och tilldelning av telefonnummer. Användarens arbetstelefonnummer måste vara i +E.164-format, förinstallerat och tilldelat en giltig plats för att licensen ska aktiveras automatiskt. Om dessa villkor inte uppfylls kommer användaren inte att tillhandahållas tjänster automatiskt och kan kräva manuell ingripande.
Sammanfattningsvis konfigurerar du organisationsbaserad automatisk licensiering för nya användare om du vill ha en bred, organisationsomfattande licenstilldelning. Om du föredrar mer detaljerad kontroll eller har olika licensbehov per grupp konfigurerar du automatisk licensiering på gruppnivå och undviker tilldelning av licenser på organisationsnivå för att förhindra överlappning och säkerställa korrekt licenshantering.
Webex Calling Serviceinställningar
Det är viktigt att genomföra en omfattande granskning och konfiguration av de globala service inställningarna inom.
Börja med att komma åt och navigera till inställningsavsnittet. Undersök noggrant varje konfigurerbart alternativ, inklusive, men inte begränsat till, intern uppringningskonfiguration, nödsamtalsparametrar, samtalsrutningspolic yer, röstbrevlådehantering och enhetens standardinställningar.
Justera de globala inställningarna så att de återspeglar organisationens policyer och designbeslut.
Också, inställningsinställningar och användar- och appmallar.
Pilotmigrering
Under implementeringsfasen, genomförandet av en pilotmigration representerar en kritisk milstolpe för att validera övergången från till. Detta pilotprojekt innebär att en representativ delmängd av användare etableras på en eller flera platser på plattformen, vilket säkerställer att den valda populationen återspeglar olika användningsfall och organisatoriska roller. Parallellt med användarmigrering måste viktiga samarbetstjänster inklusive röstbrevlåda, automatiska sköer, samtalsköer och jaktgrupper övergå till sina motsvarigheter för att upprätthålla affärskontinuitet och tjänstefunktionalitet.
Pilotmigreringen bör utnyttja samma kombination av Cisco-tillhandahållna verktyg och migreringsverktyg från tredje part som planeras för den bredare organisatoriska distributionen, vilket säkerställer att processer, automatiseringsarbetsflöden och integrationspunkter valideras noggrant under representativa förhållanden.
De primära målen för denna pilotdistribution är tvåfaldiga: för det första, att validera och förfina övergångsprocesserna från början till slut inklusive arbetsflö den för användarprovisionering, datami greringsprocedurer, och slutpunktskonfigurationer; och för det andra, att fullständigt verifiera funktionaliteten hos migrerade tjänster under verkliga operativa förhållanden.
Detta stegvisa tillvägagångssätt gör det möjligt för projektgruppen att identifiera och åtgärda eventuella tekniska eller procedurmässiga problem i en kontrollerad miljö, samla in feedback från användare om den nya plattformsupplevelsen, bedöma effektiviteten hos utvalda migr eringsverktyg och skapa förtroende för migreringsm etoderna innan de fortsätter med en bredare organisatorisk distribution.
De insikter som erhållits under denna pilotfas är avgörande för att optimera efterföljande migrationsvågor och säkerställa en smidig, riskreducerad övergång för hela företaget.
Skaffa PSTN
För att anskaffa PSTN-tjänster för, välj först ett PSTN-anslutningsalternativ i.
Om en organisation planerar att upprätthålla hybrid dubbel samtalskontroll (fas 1 i figur Fasad samtalsövergång: Hybrid och mol n) antingen tillfälligt eller på obestämd tid, måste de distribuera en eller flera lokala gateways för lokalt PSTN för att tillåta samtal mellan och slutpunkter.
Om en fullständig övergång (fas 2) till molnet är slutmålet inklusive PSTN, krävs antingen en Cisco-samtalsplan eller ett Cloud Connect for alternativ för PSTN.
Arbeta med din valda leverantör för att beställa och portera telefonnummer innan du konfigurerar dem. Beställning av telefonnummer eller initiering av portbeställningar krävs/möjligt endast för lokal PSTN och Cloud Connect för. För Ciscos samtalsplaner initieras beställning och portering inifrån Control Hub så snart platsen har skapats och i länder där Cisco Calling Plan är tillgängligt. Mer information om Cisco-samtalsplaner finns i Kom ma igång med C isco-abonnemang.
Som en del av PSTN-implementeringen, se till att din leverantör har aktiverat både inkommande och utgående PSTN-tjänster för din plats. Utför dessutom testsamtal för att verifiera att samtal dirigeras korrekt via din valda PSTN-anslutning.
Konfigurera platser
Innan du lägger till användare och enheter i måste du tillhandahålla samtalsplatser. För varje plats måste en giltig gatuadress anges. I USA och Kanada valideras denna adress och används av plattformen för att skicka PIDF-LO-platsinformation för nödsamtal.
När du konfigurerar platser som använder lokal PSTN måste du konfigurera de lokala gatewayerna i enlighet med detta. I måste en trunk och en ruttgrupp skapas för varje lokal gateway, och rutt gruppen tilldelas sedan som PSTN-val för platsen. Cisco rekommenderar starkt att du alltid väljer en ruttgrupp som PSTN-val, eftersom detta tillvägagångssätt gör att du enkelt kan lägga till ytterligare trunkar i framtiden, vilket stöder både skalbarhet och redundans. Cisco rekommenderar också att du aktiverar stöd för dubbel identitet och P-Charge-Info på varje PSTN-trunk, eftersom detta förenklar identifieringen av den fakturerbara parten för utgående direkta eller omdirigerade samtal. Om din PSTN-leverantör använder en annan rubrik för fakturering kan du kopiera informationen från P-Charge-Info-rubri ken på den lokala gatewayen till den obligatoriska faktureringsrubriken.
För platser som använder Cloud Connect för eller Cisco Calling Plan som sitt PSTN-alternativ, välj helt enkelt respektive PSTN- val för platsen under installationen. Om platsen använder antingen Cloud Connect för eller lokalt PSTN måste du lägga till de telefonnummer som beställdes i föregående steg. Nummer kan läggas till som inaktiva om du inte vill att de ska inkluderas i samtals dirigering direkt; du kan aktivera dessa nummer senare när de tilldelas användare eller funktioner.
Det är viktigt att alltid ställa in huvudnumret för varje plats. Huvudnumret kan tilldelas antingen en användare eller en funktion, till exempel en automatisk skötare. För att aktivera röstbrevlådan på platsen, se till att ställa in röst brevlådans pilotnummer, även känt som röstportalnumret.
Ytterligare inställningar för samtalsplatser inkluderar konfigurering av nödsamtalsinformation som nödsamtalsnummer, meddelande alternativ och förbättrade nödsamtalsfunktioner. Du bör också granska och justera inspelningsinställningar, språkinställningar och enhetskon figurationer efter behov för varje plats. Om din organisation använder förkortad internetuppringning mellan platser med betydande företags nummer, kom ihåg att konfigurera en unik platskod för platsen i de interna uppringningsinställ ningarna. Slutligen, om extern uppringning kräver en siffra för utgående uppringning, se till att ställa in detta i inställningarna för extern uppr ingning. När en utgående uppringningssiffra är konfigurerad rekommenderar Cisco att du aktiverar utgående uppringningssifferverkning för att säkerställa enhetlighet.
Integration med lokal samtalskontroll
För att integrera med lokal samtalskontroll är det nödvändigt att konfigurera trunkar, ruttgrupper, företagsuppringningsplaner och både platsinställningar och globala inställningar. Börja med att ställa in trunkar och lokala gateways avsedda för sammankoppling med det lokala samtalskontrollsystemet. Detta steg krävs endast om dedikerade trunkar är nödvändiga. Om befintliga trunkar och ruttgrupper är tillräckliga för distributionen kan de återanvändas för den lokala sammankopplingen utan ytterligare konfiguration.
När stammarna och ruttgrupperna har upprättats fortsätter du med att skapa företagets uppringningsplaner och tilldela lämplig ruttgrupp som destination för varje uppringningsplan. När integrationen involverar flera lokala samtalskontrollsystem som är anslutna via olika trunkar krävs flera uppringningsplaner. Det är viktigt att se till att uppr ingningsplanerna endast innehåller de mönster som krävs för att dirigera samtal till lokala destinationer.
Om distributionen kräver stöd för okänd tilläggsrouting bör den här funktionen vara aktiverad på platsnivå. Dessutom, när routning av okänd anslutning är aktiverad, måste du ange den maximala okända förlängningslängden i avsnittet Samtalsdirigering mellan och lokaler i inställningarna för samtalstjänster i. Detta säkerställer sömlös samtalsdirigering och korrekt hantering av tilläggsbaserade uppringnings scenarier i din integrerade miljö.
Migrera användare i grupper
När du migrerar användare från till kan du kanske inte flytta alla användare samtidigt. Detta kan bero på flera orsaker, inklusive men inte begränsat till antalet webbplatser eller användare, hur lång tid det tar att överföra en webbplats och/eller grupp användare samtidigt, begränsad IT- eller webbplatsresurs för att stödja ändringsfönstret, varaktighet för ändringsfönstret, förändringens komplexitet etc.
När du migrerar användare i faser är det viktigt att identifiera vilka användare som behöver migrera tillsammans i samma batch. Det primära målet är att migrera användare tillsammans som har beroenden med varandra för sina samtalstjänster och funktioner. Du vill se till att alla deras samtalsfunktioner (Exempel - Samtalsköer) fungerar fullt ut som de var innan övergången aktiverades.
Även om du implementerar samtalssamarbete mellan och med lokala gateways kan du inte dela delade tjänster eller funktioner över den här anslutningen. Därför måste du identifiera beroenden mellan användare genom att titta på funktioner som:
-
Övervaka andra användare som använder BLF:er
-
I samma jaktpilot, samtalskö, etc
-
Delade linjer
-
Använda uppringningsupptagning
-
Använda samma call-park-nummer
-
Intercom
-
Verkställande direktör/administratör.
Ett exempel skulle vara en användare som ingår i en Hunt Group som övergår till. Denna användare kommer att övergå till med Hunt Group och med alla andra medlemmar i Hunt Group. Därför kan Hunt Group och dess medlemmar framgångsrikt svara på samtal på den nya plattformen efter övergången.
Detta blir mer utmanande när användare är anslutna till olika grupper av användare för olika samtalstjänster och funktioner. Detta kräver att mer än en grupp användare och en samtalstjänst övergår till samtidigt.
Använd utdata från verktyget Migration Insights eller tredjepartsverktyg som du använde i förberedelsefasen för att avgöra vilka användare och funktioner som ska grupperas tillsammans. Denna utdata borde ha använts för att utveckla din migreringsplan och ger dig insikter om hur du grupperar användare och funktioner som behöver övergå tillsammans.
De viktigaste stegen när du övergår en grupp användare är:
-
Identifiera användare att migrera tillsammans
-
Kontrollera att alla användare är inne
-
Kontrollera att alla TN för användarna finns i
-
Kontrollera korrekt telefonnummerformat i katalogen
-
Kontrollera att licensierings- och inställningsmallen för användargrupperna är korrekt inställd
-
Verifiera eller konfigurera alla samtalstjänster och funktioner för användar gruppen (före eller under övergången beroende på vad som är lämpligt)
-
Lägg till användare i gruppen av samtalsaktiverade användare i företagskatalog en
-
Utnyttja verktyg - verktyg för migrering av användare och funktioner och/eller verktyg från tredje part
-
Inaktivera/ta bort användare/enhetskatalognummer och samtalsfunktioner/tjänster på efter övergången.
Efter migrering av en grupp användare testar du en delmängd av användarna för att kontrollera att alla deras samtalsfunktioner och tjänster fungerar korrekt. Om samtalsfunktioner som samtalskö, jaktgrupper etc. överförs med gruppen användare, testa sedan dessa samtalstjänster för korrekt funktionalitet.
Arbetsytor
I hänvisar en arbetsyta till en delad plats (som ett konferensrum, mötesutrymme eller ett funktionellt skrivbord) som kan tilldelas enheter, tillägg och användare. Till skillnad från traditionella Unifed CM- telefoner är arbetsytor:
-
Platscentrerad: knuten till fysiska utrymmen.
-
Enhetsflexibel: kan ha en eller flera enheter (skrivbordstelefoner, kort etc.).
När arbetsytor har identifierats som en del av övergången till kan de läggas till under Enheter. Varje arbetsyta behöver en enhetstilldelning, och om de redan Unified CM finns i måste de återställas eller etableras om. funktioner som röstbrevlåda, vidarekoppling och upphämtning av samtal kan aktiveras eller inaktiveras, och policyer kan tillämpas för videosamtal, samtalsparkering och rörlighet efter behov. Testa varje arbetsyta genom att ringa interna och externa samtal, testa video-, konferens- och mobil itetsfunktioner. Slutligen, låt användarna veta om alla tillämpliga processer för arbetsyteenheter och bokningar.
Försörjningsenheter
Telefoner som för närvarande är registrerade på måste migreras till som en del av molnövergången. För att göra migreringen så enkel som möjligt med minimal risk för misslyckande rekommenderar Cisco att migrera fysiska webbplatser eller avdelningar samtidigt. Du kan dock behöva migrera användare i grupper på grund av funktionsberoenden. Se avsnittet Migrera användare i grupper för mer information.
Alla telefoner som stöds som du behöver övergå från måste konfigureras som användare eller arbetsyta och den fysiska telefonen måste konfigureras om för att registrera dig med . Dessutom behöver telefonerna i 7800- och 8800-serien sin firmware uppgraderad från Enterprise- firmware till Multiplatform Phone (MPP) firmware. Denna process inkluderar laddning av övergångs firmware innan du laddar den MPP-firmware som krävs för registrering. Det kräver också lämplig migrationslicens. Cisco har förbättrat denna process under de senaste åren för att göra det lättare för dig att uppgradera dina Enterprise-firmware- telefoner till MPP-firmware. Mer information om stegen för att slutföra uppgraderingen av den inbyggda programvaran finns i Konvertera Cisco 7800- och 8800-seriens IP-telefoner mellan Enterprise- och MP P-firmware.
Förutom stegen som beskrivs i den här artikeln finns det ett inbyggt verktyg, Migrera telefonen till Webex Calling, som du kan använda för att hjälpa till att migrera dina 7800- och 8800-telefoner från Enterprise till MPP-firmware. Med det här verktyget kan du också lägga till telefonerna och tilldela dem till lämpliga användare eller arbetsytor. Mer information om verktygsanvändning finns i Migrera telefonen.
För telefoner i 9800-serien som är registrerade med ovanstående krav på migrering av firmware gäller inte. Dessa telefoner kör PhoneOS, som stöds av både och. För att överföra dessa telefoner till måste du lägga till demWebex Calling, tilldela dem till en användare eller arbetsyta och sedan fabriksåterställa telefonerna. PhoneOS startsekvens för registrering Figur nedan visar PhoneOS-startsekvensen och hur telefonen kommer att registrera sig när den har lagts till, även om telefonen fortfarande är etablerad och/eller DHCP-alternativ (Exempel - 150) används.
stöder fabriksåterställning av PhoneOS-enheter för att möjliggöra Zero-Touch-onboarding till. administratörer kan fjärråterställa 9800- och 8875-telefonerna via CUCM-administrations sidorna, vilket eliminerar behovet av fysisk åtkomst till telefonerna för att ombordlägga telefonerna till. Den här funktionen stöds med enhetspaketen från 9 september 2025:
-
CUCM v15 - Unified Communications Manager version 15
-
CUCM v14 - Unified Communications Manager version 14.
För mer information om registreringsprocessen för 9800-serien, se Registrerings process.
Förutom Ciscos IP-telefoner kan det krävas tillhandahållande av andra enheter som analoga telefon adaptrar (ATA), trådlösa (Wifi, DECT) telefoner, videoenheter, röstgateways och tredje part senheter och telefoner. Många av dessa enheter har ingen uppgraderingsväg för firmware som IP-telefonerna för att överföra dem från företags firmware till moln programvara. Därför kommer du att tillhandahålla var och en av dessa enheter i Control Hub. Vissa av dessa kan inte övergå till och motsvarande modell kommer att behöva ersätta den (t.ex. ATA 191/192) och andra kommer att kräva manuell omkonfiguration och/eller programändringar.
- Röstgateways — Om du vill migrera den lokala gatewayen finns i Mi grera lokal gateway.
-
Analog telefonadapter (ATA) - För att komma igång med Cisco ATA 191 och 192, se Cisco ATA.
-
Trådlös Wifi-telefon - För att integrera trådlös telefon 840 och 860, se Integrera trådlös Webex-telefon.
-
Trådlösa DECT-telefoner - För att komma igång med din nya Cisco IP DECT 6800-serie, se Cisco IP DECT.
Information om hur du bygger och hanterar digitalt DECT-nätverk i Control Hub finns i Hantera DEC T-nätverk
Mer information om Cisco IP DECT 6800 finns i Installationsguide
-
Tred je partsenheter och telefoner - Arbeta med tredje part sleverantörer om enhets-/telefonkrav och processen för att migrera eller ersätta dem för att stödja.
Konfigurera funktioner
Alla samtalsfunktioner som krävs måste etableras före eller under övergången. Som diskuterats under avsnittet Migrera användare i grupper måste anropsfunktionerna konfigureras och övergå när användarna som använder dem övergår.
Mer information om hur du konfigurerar var och en av funktionerna finns i motsvarande konfigurationshjälpartiklar.
-
Automatiska skötare — För att hantera automatiska skötare, se Automatiska skötare
-
Samtalsparkering - För att hantera samtalsparkering, se Call park
-
Upphämtning av samtal — Om du vill konfigurera samtalsupphämtningsgrupp finns i Upph ämtning av samtal
-
Samtalsköer - För att konfigurera samtalskö, se Samtalsk ö
-
Jaktgrupper — Om du vill hantera jaktgrupper finns i Hantera jakt grupp
-
Driftlägen - Om du vill dirigera samtal baserat på driftlägen, se Sam talsdirigering baserat på driftlägen
-
Personsökningsgrupper — Mer information om hur du konfigurerar en personsökningsgrupp finns i Konfigurera en personsökningsgrupp
-
Inspelningar - För att hantera samtalsinspelning för, se Hantera inspelningar
-
Räckvidd för enstaka nummer - Om du vill konfigurera räckvidd för enstaka nummer (kontor var som helst), se Konfigurera enstaka nummer
Acceptansprovning
Godkännandetestning säkerställer att den migrerade miljön uppfyller funktionskraven, fungerar som förväntat och levererar en sömlös användarupplevelse i alla kommunikationsflöden. Denna validerings process är mångfacetterad och täcker allt från användarprovisionering och nummertilldelning till operativa prestanda för avancerade samtal sfunktioner.
Det här avsnittet innehåller exempel och belyser viktiga aspekter att tänka på under godkännandetestning; i alla fall, det är inte avsett att fungera som en uttömmande eller omfattande checklista.
Tilldelning av användare och nummertilldelning
En grundläggande aspekt av acceptanstestning innebär att verifiera att alla användare är etablerade korrekt och fullständigt inuti. Detta kräver en grundlig jämförelse mellan source () -katalogen och den nyetablerade användarbasen för att säkerställa att varje användarkonto, tillsammans med tillhörande attribut som an knytningsnummer och DID-tilldelningar (Direct Inward Dip) har migrerats korrekt. Fullständigheten av provisioneringen är avgörande inte bara för driftbarheten dag ett utan också för pågående administration och support.
Validering av nummertilldelning inkluderar bekräftelse av att varje användare tilldelas rätt anknytning och externt nummer, och att dessa nummer dirigeras korrekt i både interna (på nätet) och externa (PSTN) samtalsflöden. Det är viktigt att kontrollera om det finns överlappningar, saknade tilldel ningar eller felkonfigurationer som kan leda till samtalsroutningsfel eller serviceavbrott.
PSTN-samtalsflöden och presentation av uppringnings-ID
Ett robust förfarande för acceptanstestning måste omfatta end-to-end- validering av PSTN-samtalsflöden. Detta inkluderar både inkommande och utgående samtalsscenarier. För inkommande PSTN-samtal bör testteamet bekräfta att samtal levereras till de avsedda slutpunkterna, oavsett om det är enskilda användare, samtalsköer, jaktgrupper eller automatiska sköer. Utgående PSTN-samtal måste göras framgångsrikt, med särskild uppmärksamhet på korrekt leverans och presentation av uppringnings-ID-information. Detta innebär att se till att rätt uppringarens namn och nummer visas för externa mottagare, i enlighet med organisationens policyer och myndighetskrav.
Testning bör också ta itu med failover-scenarier, till exempel hantering av oåtkomliga slutpunkter eller nätverksstörningar. Detta hjälper till att bekräfta att reserv mekanismer och alternativ routing fungerar korrekt, vilket upprätthåller tjänstekontinuitet och tillförlitlighet.
Samtalsflöden på nätet
Interna, eller on-net, samtalsflöden utgör ryggraden i företagskom munikation. Godkännandetestning i detta område verifierar att samtal mellan användare inom organisationen dirigeras korrekt, med funktioner som samtalsöverföring, kvarhållande, vidarekoppling och konferenser som fungerar som avsett. Integriteten för uppringningsplaner, anslutning mellan tillägg och tillägg och stöd för organisations samtalspolicyer måste alla bekräftas.
Hantering av användarsamtal och funktionsvalidering
En viktig aspekt av acceptanstestning innebär att validera hur användare hanterar samtal med hjälp av skriv bord stelefoner som stöds. Denna process fokuserar på att bekräfta att dagliga samtals flöden är intuitiva och pålitliga, och att användare har sömlös åtkomst till de kärn funktioner som är nödvändiga för deras roller. Testning bör bedöma hur enkelt användare kan ringa och ta emot samtal, hantera håll nings- och återupptagningsfunktioner, och utföra både blinda och rådgivande överföringar. Det är också viktigt att verifiera att vidarekoppl ing, konferenser och andra avancerade funktioner, såsom parkering och hämta samtal eller aktivera stör ej, är lättillgängliga och fungerar smidigt.
Upplevelsen bör utvärderas för tydlighet och lyhördhet, med tanke på hur användare interagerar med samtalshistorik, röstbrevlåda och integrerade kataloger. Ytterligare uppmärksamhet bör ägnas åt möjligheten att flytta aktiva samtal mellan enheter och att använda samtalskontroller effektivt inom applikationen eller på fysiska telefoner. Det slutliga målet är att säkerställa att slutanvändarupplevelsen är konsekvent, effektiv och fullt ut stöder organisationens kommunikationsbehov efter migreringen.
Samtalsköer: Erfarenhet av agent och handledare
Samtalsköer används ofta för att hantera scenarier för inkommande samtal med stora volymer. Acceptansprovning fokuserar här på flera dimensioner. Först bör det verifieras att samtal distribueras till agenter enligt den konfigurerade kölogiken, till exempel round robin, längsta tomgång eller samtidig ring. Presentationen av köade samtal på agentskrivbord måste undersökas för tydlighet och användarvänlighet, så att agenter effektivt kan acceptera, hålla och överföra samtal.
För handledare bör skrivbordsupplevelsen utvärderas för funktioner som realtidsövervakning, samtalspråkning och analys eller in sikter om köprestanda. Detta inkluderar men är inte begränsat till validering av instrumentpaneler och rapporteringsverktyg som tillhandahåller handlingsbara data om samtals distribution, agentaktivitet och kömätvärden.
Jaktgrupper: Samtalsfördelning
Jaktgrupper är en nyckelmekanism för att distribuera samtal till fördefinierade uppsättningar användare. Acceptanstestning måste bekräfta att samtal dirigeras till gruppmedlemmar baserat på den konfigurerade jaktalgoritmen, och att scenarier för överflöd, vidarebefordran och inget svar hanteras enligt design. Att säkerställa att gruppmedlemskap och samtalsroutningsbeteenden matchar de som tidigare fastställts i är avgörande för operativ konsistens och användartillfredsställelse.
Automatiska mottagare: Meddelanden och menyåtgärder
Automatiska skötare representerar frontlinjen för automatisk samtalshantering. Testningen måste omfatta uppspelning av meddelanden, noggrannheten hos inspelade hälsningar och korrekt funktion av menyträd. Meny val bör på ett tillförlitligt sätt dirigera uppringare till lämpliga avdelningar, individer eller externa nummer. Testning bör också innehålla ogiltiga scenarier eller timeout-scenarier för att bekräfta att uppringare får tydlig vägledning eller omdirigeras som avsett.
Röstbrevlådeoperation
Slutligen är röstbrevlådans funktionalitet avgörande för användarupplevelsen. Godkännandetester bör verifiera att röstbrevlådor är korrekt tilldelade och tillgängliga, både inifrån organisationen och på distans. Möjligheten att spela in, hämta och hantera meddelanden måste bekräftas, tillsammans med aviseringsleverans.
Optimera
PSTN-migrering till Cloud Connect för
När alla slutpunkter och användare har migrerats till molnanrop Unified CM är det enda syftet att fungera som en transit mellan PSTN-gateways och via Local Gateway. Att ta bort PSTN-gateways och Local Gateway från bilden genom att använda Cloud Connect som PSTN-åtkomst för alla Webex Calling användare har flera fördelar, inklusive kostnads minskning och förbättrad tillförlitlighet. Så här övergår du till lokal PSTN-åtkomst till Cloud Connect för :
-
Cloud Connect för partnerval.
Se listan över Cloud Connect för partners och välj bland de tillgängliga partnerna som är tillgängliga för din organisations plats.
-
Cloud Connect för validering.
Innan du byter PSTN-åtkomst för platser till Cloud Connect bör anslutningen till PSTN via den valda Cloud Connect-partnern verifieras och valideras. För detta ändamål måste en testplats etableras med vissa testanvändare etablerade på den testplatsen. PSTN-åtkomst för den här test platsen ställs sedan in på Cloud Connect-partnern innan PSTN-anslut ningen valideras med testtelefonerna. Efter lyckad validering kan testplatsen avprovisioneras.
-
Nummerportering.
För att förbereda för övergången till Cloud Connect måste en portorder för alla nummer som för närvarande är tilldelade PSTN-trunken som avslutas placeras. Alla nummer måste överföras till Cloud Connect-partnern. För att bibehålla åtkomligheten mellan lokaliseringar måste alla nummer på alla platser portas samtidigt .
-
Byt till Cloud Connect-partner.
Vid tidpunkten för övergången måste PSTN-åtkomst för alla platser i ställas in till Cloud Connected PSTN-leverantören, och inkommande och utgående anslutning bör verifieras.
Som diskuterats i avsnittet PSTN i designkapitlet kan kunder också välja att flytta sin PSTN-åtkomst till Cloud Connect för i början av övergången med hjälp av PSTN-trunking för hybriddistributioner. Mer information finns i PSTN-trunking för hybriddistributioner. Webex Calling I det fallet under övergången sker PSTN-åtkomst för via lokal gateway och efter att alla användare flyttats till finns det inget ytterligare PSTN-relaterat migreringssteg annat än avveckling och de lokala gatewayerna.
Optimera lokal infrastruktur
När alla användare har övergått till och alla slutpunkter har övergått till molnregistrering (eller har avvecklats ) uppdaterar du lämplig lokal infrastruktur nu när molnsamtal används. Uppdateringar av infrastrukturen inkluderar:
-
Ta bort lokala samtalskontroll- och meddelande DNS SRV poster från den lokala DNS-servern (erna) inklusive cisco_uds. _tcp. <domain>, cup_inloggning. _tcp. <domain>. Dessa SRV-poster krävs inte längre för identifiering av klienttjänster.
-
Ta bort kantrelaterade DNS SRV poster från det offentliga DNS-systemet inklusive collab_edge. _tls. <domain>. Dessa SRV-poster krävs inte längre för att upptäcka klienttjänster för gräns tjänster för samarbete.
-
Uppdatera alla relevanta DHCP-omfattningar för att ta bort alternativ 66 och alternativ 150 TFTP/startserveradresser. Dessa omfattningar krävs inte längre för identifiering och nedladdning av konfiguration av slutpunktssamtalskontroll.
-
Uppdatera/ta bort lämpliga uppringningspartners i Lokal gateway/kub som dirigerar samtal till och från. Unified CM Dessa uppringningspartners behövs inte längre för lokal samtalsdirigering.
-
Ta bort eller ta bort alla virtuella datorer och/eller servrar i klusternoder. Återanvänd beräkningsresurser och hårdvara efter behov. Dessa resurser behövs inte längre för samtalskontroll och edge-tjänster.
-
Ta bort eller ta bort alla virtuella datorer och/eller servrar i klusternoder. Återanvänd beräkningsresurser och hårdvara efter behov. Dessa resurser behövs inte längre för röstbrevlåda och enhetliga meddel andetjänster.
-
Rensning: Efter migrering av PSTN-åtkomst till Cloud Connected PSTN kan PSTN-trunkar, PSTN-gateways och Local Gateway avvecklas.
-
För alla befintliga lokala E911-lösningar tar du bort alla platser eller nummer som har migrerats till och när fullständig övergång är klar tar du bort virtuella programmaskiner eller servrar. Återanvänd beräkningsresurser och hårdvara efter behov. Dessa resurser behövs inte längre för nödsamtal och lokaliseringstjänster.
-
DN:er som tillhör migrerade användare bör placeras i en dold partition för att undvika fel på samtalsroutning och för att säkerställa att alla CSS-servrar har prioriterad åtkomst till molnsökvägen för samma DN:er.
-
Uppdatera den fysiska avsändningsplatsen och nätverkselementet i horisontmobilitet när förändringar inträffar. Vanliga aktiviteter som kräver uppdateringar är:
-
Byte av nätverksswitch
-
Ersättning av trådlös åtkomstpunkt
-
Ändringar av DHCP-omfattning
-
Fysiska förändringar inne i byggnaden (om de löses till kubikal/kontor)
-
Fysisk kontorslokalens expansion eller sammandragning inuti en byggnad.
-
Använd analys och felsökning
tillhandahåller omfattande analys- och felsökningsfunktioner som hjälper dig att visualisera och spåra din distribution. Dessa täcker mediekvalitet, detaljerad samtalshistorik, samtalskö, jakt grupp, och automatisk skötanalys. Ett exempel på mediekvalitetsanalys visas i figur mediekvalitetsanalys.
Under felsökning kan varje samtal som görs med hjälp av visas med detaljerad information om viktiga mediekvalitet och signalrelaterade problem för att hjälpa till att identifiera medieproblem såväl som misslyckade samtal, som visas i felsökning av medi ekvalitet i figuren.
Felsökning kan också integreras med andra Cisco-produkter som ThousandEyes och Meraki- switchar för att ge en ännu rikare integrerad upplevelse i Control Hub. Mer information om hur du använder Webex Callinganalys och felsökning finns i Felsöka Webex Calling samtal i Control Hub.
Inledning
Innan du börjar
Den här guiden är avsedd för team eller individer med erfarenhet av att konfigurera och administrera Cisco Unified Communications Manager (Unified CM) och Cisco-slutpunkter, inklusive IP-bordstelefoner, videoenheter och Jabber-programklienter. Genom hela det här dokumentet finns länkar till produkt- och supportdokumentation som kan vara till hjälp.
Det här dokumentet fokuserar endast på övergångar från Unified CM till Webex Calling med flera hyresgäster. Termen Webex Calling i det här dokumentet hänvisar alltid till Webex Calling med flera hyresgäster.
Innan migreringen från Unified CM till Webex Calling påbörjas är det absolut nödvändigt att ha en omfattande förståelse för Webex Calling-lösningen och dess respektive komponenter. En lyckad migrering kräver bekantskap med Webex Calling-arkitekturen, servicemodeller, distributionsalternativ och tillhörande funktioner för att korrekt kartlägga befintliga Unified CM-arbetsbelastningar och utforma en effektiv övergångsplan.
En grundlig förståelse av följande Webex Calling-komponenter är avgörande för att informera en effektiv övergångsstrategi och operativ beredskap.
-
Control Hub
-
Katalog- och användarprovisionering
-
Webex Calling-plattform
-
Stödda samtalsslutpunkter
-
PSTN-anslutningsalternativ
-
Webex Calling uppringningsplan och nummerhantering
-
Säkerhets- och efterlevnadsfunktioner.
För mer information, se Ciscos föredragna arkitektur för Webex-samtal.
Den här guiden kommer att belysa verktyg och processer som ska användas under hela övergångscykeln. En övergång från lokala samtal, Unified CM, till en ny molnbaserad samtalsplattform, Webex Calling, kan dock vara en betydande ansträngning med potentiella affärsmässiga, tekniska och komplexa utmaningar. För att hjälpa dig att övervinna dessa utmaningar har Cisco några olika alternativ tillgängliga för att hjälpa dig på din resa. Det är viktigt att granska informationen på Företagsmolnsamtal - Samtalsmigrering och förstå varje alternativ och hur vart och ett kan hjälpa dig med din egen migrering.
-
Webex-migreringsverktyg: självbetjäningsverktyg, kostnadsfria verktyg inbyggda i Control Hub för att effektivisera din övergång till Webex Calling
-
Certifierade migreringsleverantörer: Cisco-validerade programvaru- och verktygsleverantörer som har utvecklat migreringslösningar för att hjälpa Webex-partners och kunder med komplexa och stora migreringar. Dessa lösningar kan hjälpa till att förenkla, hantera och påskynda övergången till Webex Calling.
-
Webex installationshjälp: en Cisco-ledd migreringstjänst som vägleder kunder och partners genom Webex Calling-distributionen och konfigurationen, vilket behövs för att framgångsrikt migrera Unified CM-användare och -tjänster till Webex Calling.
Översikt
Med tillväxten av molnbaserade samarbetstjänster vill fler kunder flytta sina befintliga samarbetsbelastningar till molnet, med tanke på löftena om minskad total ägandekostnad, förenklad hantering, kontinuerlig leverans av funktioner, ökad skalbarhet och överlägsen tillförlitlighet som är inneboende i molnbaserade tjänster. När kunder vill övergå från lokala till molnbaserade samarbetstjänster är det viktigt för dem att förstå vad övergången innebär och vilka steg som krävs för att genomföra övergången.
Syftet med det här dokumentet är att ge distributionsvägledning för kunder som specifikt vill övergå från lokal Unified CM till Webex Calling i molnet. Den här distributionsguiden förutsätter att läsaren har en grundläggande förståelse för samtalsövergången mellan Unified CM och Webex Calling, inklusive vad som ändras vid denna övergång och vilka skillnaderna är när samtalsarbetsbelastningen flyttas från lokalt till molnet. Innan du fortsätter, se till att du har granskat och är bekant med informationen som finns i Övergångskartan. Detta övergångskartdokument ger information om förändringarna och skillnaderna i denna övergång.
Som visas i figur Arkitektur för lokalt samarbete: Samtalskontroll och fjärråtkomst, en typisk lokal implementering inkluderar olika samarbetsinfrastrukturkomponenter i nätverket, en samtalskontrollplattform, en edge-plattform, hårdvaru- och mjukvaruslutpunkter och i vissa fall till och med konferens- och schemaläggningsplattformar. I Cisco-arkitekturen skulle detta inkludera Unified CM för samtalskontroll, Expressway för fjärråtkomst och företagsbaserade (B2B) edge-tjänster, Cisco Meeting Server / Cisco Meeting Management för lokala konferenser, Unity Connection för röstmeddelanden och användarvänlig hårdvara (Cisco IP-telefoner, Cisco Desk- och Room-videosystem) och programvara (Cisco Jabber) för IP-baserade slutpunkter. Dessa komponenter kan variera något i vissa miljöer, men detta är utgångspunkten för övergången som beskrivs i resten av detta dokument.
Arkitekturen som visas i figur Arkitektur för lokalt samarbete: Samtalskontroll och fjärråtkomst är baserad på Preferred Architecture (PA) för Cisco Collaboration Enterprise On-Premises Deployments. För mer information om Enterprise On-premise, se Ciscos föredragna samarbetsarkitekturer.
Före: Tabellen Komponenter för lokala samtalsinfrastrukturer listar de viktigaste elementen i den lokala arkitekturen före övergången till Webex Calling i molnet.
| Produkt | Beskrivning |
|---|---|
| Unified CM | Lokal samtalskontroll som tillhandahåller enhetsregistrering och samtalsdirigeringstjänster |
| Cisco Expressway-C/E | Edge-infrastruktur som tillhandahåller mobil och fjärråtkomst (MRA) och företag-till-företag (B2B)-funktionalitet som gör det möjligt för fjärrslutpunkter att ansluta säkert från utsidan av organisationen. Expressway distribueras parvis för att tillhandahålla brandväggsgenomgång för externa slutpunkter. |
| Cisco Meeting Server (CMS), Cisco Meeting Management (CMM) och Cisco Telepresence Management Suite (TMS) | Lokal infrastruktur för röst-, video- och webbkonferenser som tillhandahåller flerpunktsmöten, möteshantering och schemaläggningsfunktioner. [Optional] |
| Cisco Unity Connection | Lokal röstmeddelandeplattform som tillhandahåller funktioner för röstbrevlåda och enhetlig meddelandehantering. [Optional] |
| Cisco Desk, Cisco Room, Cisco Board, Cisco IP-telefoner och Cisco Jabber | IP-baserade enheter registrerade i Unified CM och som erbjuder röst- och videosamtal |
Som illustreras i figur Övergångsbeslut: Lokala samtal till Webex Calling, kunder som har lokal samtalskontroll med Unified CM och IP-slutpunkter för skrivbord och video kan välja att övergå till en Webex Calling-molnarkitektur.
Beslutet måste fattas baserat på kundens funktionskrav. Kunder som har följande krav bör noggrant överväga detta innan de fattar detta beslut och kan slutligen besluta att behålla samtalskontrollen lokalt:
- Telefonmodeller som inte stöds av Webex Calling
- Komplexa eller många integrationer med andra lokala system eller lösningar, särskilt där det är svårt att replikera dessa integrationer med Webex Calling eller inga motsvarande alternativa lösningar finns tillgängliga.
- Komplex uppringningsplan, mycket detaljerade serviceklasser eller båda
- Begränsad, begränsad eller opålitlig internetåtkomst
- Strikta policyer för dataskydd och äganderätt
- Efterlevnadskrav för inspelning och lagring av media på plats eller i landet
- Tredjepartsintegrationer utan en fungerande alternativ Webex Calling-integration
- Kontaktcenterintegrationer där kontaktcenterintegrationen inte flyttas till molnet ännu.
Det här dokumentet fokuserar på kunder med Unified CM-samtalskontrolldistributioner som vill förstå de allmänna stegen, övervägandena och kraven för att aktivera Webex Calling-distribution enligt beskrivningen i nästa avsnitt.
Kärnkomponenter
Målarkitekturen för den här migreringen innehåller flera nya komponenter. Detta inkluderar Webex Calling-tjänsten för molnbaserade samtal, Webex-appen, Cisco Directory Connector för identitetsintegration och Local Gateway (LGW) för PSTN-åtkomst, samt integration av lokala samtal med moln. Cisco Calling Plans eller Cloud Connected PSTN (CCP) som möjliggörs av en Cloud Connect för Webex Calling-partner är ytterligare alternativ för PSTN-åtkomst.
Som visas i figur Efter: Webex Calling Architecture, de nya komponenterna (Webex Calling, Directory Connector, Local Gateway och Survivability Gateway) läggs till i den befintliga lokala distributionen.
Efter: Tabellen "Components for Cloud Calling Infrastructure Components " visar de nya elementen i arkitekturen efter övergången till Webex.
| Produkt | Beskrivning |
|---|---|
| Webex Calling | Molnbaserad samtalstjänst levererad från Webex-plattformen och tillhandahåller registrering av slutpunkt och samtalsdirigering |
| Cisco Directory Connector | Windows-program som körs på en Windows-domändator och tillhandahåller identitetssynkronisering mellan företagets lokala Active Directory och Webex-organisationens identitetsarkiv. För kunder som byter från lokal Active Directory till Entra ID använder identitetsintegrationen med Webex istället för Cisco Directory Connector Entra ID Wizard-appen. |
| Lokal gateway | En lokal gateway fungerar som en brygga mellan en kunds lokala enhetliga kommunikationsnätverk och Webex Calling-molnet. Den kan distribueras lokalt eller hostas av en partner, och leverera PSTN-åtkomst för molnregistrerade slutpunkter samt samtalsintegration mellan Unified CM-registrerade och molnregistrerade slutpunkter. Cisco IOS-XE Integrated Services Router (ISR 1100- och 4000-serien), Cisco Catalyst 8200/8300 Serien, Cisco Catalyst 8000V Edge-programvara och olika certifierade Session Border Controllers (SBC) från tredje part kan användas som en LGW för en stegvis migreringsmetod. |
| Överlevnadsgateway | Survivability Gateway (SGW) är en lokal nätverks-iOS-XE-baserad gateway som tillhandahåller reservtjänster för samtal till Webex Calling-slutpunkter på plats under nätverksavbrott. |
| Cisco-samtalabonnemang, Cloud Connect för Webex-samtal | Cisco Calling Plan och Cloud Connect för Webex Calling är molnbaserade alternativ för PSTN-åtkomst för Webex Calling-slutpunkter. PSTN-åtkomst möjliggörs av en molnbaserad PSTN-leverantör och kräver ingen lokal utrustning. |
| Webex-appen | Klientapplikation som körs på skrivbords-OS (Windows, Mac) eller mobilt operativsystem (Android, iOS) och är registrerad direkt på Webex Calling-plattformen för samtalsfunktionalitet. |
Översikt över PPDIO-processen
PPDIO-processen står för Förbered, Planera, Designa, Implementera och Optimera. Det är en strukturerad Cisco-metodik som vägleder projekt från initial utvärdering till kontinuerlig förbättring, vilket säkerställer effektiva och framgångsrika implementeringar eller migreringar.
Allmän beskrivning av PPDIO
-
Förbereda: Bedöm den nuvarande miljön, samla in krav och sammanför intressenter för att skapa en solid grund.
-
Plan: Utveckla detaljerade projektplaner inklusive tidslinjer, resurser och strategier för riskreducering.
-
Design: Utveckla mållösningen skräddarsydd för affärs- och tekniska behov.
-
Genomföra: Utför distributionen eller migreringen enligt designen, validera funktionalitet och prestanda.
-
Optimera: Förbättra lösningen kontinuerligt efter implementeringen genom att övervaka prestanda, förfina konfigurationer och utnyttja automatiserings- och integrationsverktyg.
Använda PPDIO för migreringsprojekt från Unified CM till Webex Calling
Vid övergången från Unified CM till Webex Calling ger PPDIO-processen en tydlig färdplan för att säkerställa en smidig och effektiv övergång:
Förbered
-
Utvärdera den befintliga Unified CM-miljön och migreringsberedskapen
-
Samla in detaljerad data om användare, enheter, nätverk och beroenden
-
Samla in platsinformation inklusive adress för nödsituationer, antal användare, internetåtkomst, PSTN-åtkomst
-
Identifiera risker och definiera projektets omfattning för att samordna alla intressenter.
Planera
-
Skapa en omfattande migreringsplan med batchscheman, resurstilldelningar och tidslinjer
-
Definiera uppgifter som uppgraderingar av enhetens firmware, licensprovisionering och användarintroduktion
-
Koordinera migreringsfönster med Cisco och partners för att minimera störningar.
Designa
-
Mappa aktuella Unified CM-konfigurationer, uppringningsplaner och användarprofiler till Webex Calling-motsvarigheter
-
Utforma Webex Calling-miljön, inklusive PSTN-strategi (interim och slutlig), platser, användarroller och integrationspunkter som lokal gateway (kub) och katalogsynkronisering
-
Planera för samexistensscenarier där Unified CM och Webex Calling fungerar samtidigt under migreringen.
Implementera
-
Använd migreringsverktyg för Control Hub tillsammans med verktyg från tredje part för att utföra ändringar av enhetsinbyggd programvara, funktionskonfiguration och användarmigreringar.
-
Använd massoperationer och provisionering med Webex API:er för att effektivisera storskaliga migreringar och konfigurationer
-
Utför licensprovisionering, enhetsregistrering och konfigurationsuppdateringar
-
Validera migreringens lyckade resultat genom testning och operativ verifiering.
Optimera
-
Kontinuerligt övervaka Webex Callings prestanda och användarupplevelse
-
Förfina konfigurationer och arbetsflöden baserat på operativa data och feedback
-
Utnyttja automatiserings- och integrationsfunktioner för att förbättra effektivitet och skalbarhet
-
Avveckla äldre Unified CM-komponenter vid behov och ge kontinuerlig support för daglig drift.
Denna förbättrade PPDIO-metod säkerställer en kontrollerad, transparent och effektiv migrering från Unified CM till Webex Calling, och utnyttjar Ciscos verktyg, API:er och partnerekosystem för att upprätthålla affärskontinuitet och förbättra samarbetsmöjligheter.
PPDIO-återkopplingsslingor
Översikten på hög nivå som visas i figur Iterationer vid exekvering av PPDIO illustrerar en enda återkopplingsslinga från optimeringsfasen tillbaka till förberedelsesfasen. Detta innebär att det, efter den initiala implementeringen, finns en ständig möjlighet till kontinuerlig förbättring. Varje optimeringscykel kan identifiera nya krav eller områden för förbättring, vilka kan åtgärdas genom efterföljande projekt eller initiativ. Dessa individuella projekt följer i sin tur den etablerade PPDIO-livscykeln (Förbered, Planera, Designa, Implementera, Optimera). Denna iterativa metod säkerställer att systemet förblir i linje med föränderliga affärsmål och tekniska framsteg, vilket främjar en kultur av kontinuerlig förfining och anpassningsförmåga.
Under genomförandet av PPDIO-processen är det vanligt att fynd i de senare faserna kräver omprövning och eventuellt revidering av beslut som fattats i tidigare skeden. Till exempel kan problem som uppstått under implementeringsfasen, såsom identifiering av oklarheter i designen eller saknade detaljer, avslöja att vissa aspekter inte togs upp fullt ut under designfasen. I sådana fall blir det nödvändigt att gå tillbaka till den relevanta tidigare fasen för att lösa dessa problem innan man fortsätter. Denna iterativa feedbackmekanism, som illustreras i figur Unified CM assisted PPDIO process, säkerställer att lösningen valideras och förfinas noggrant, vilket i slutändan bidrar till en mer robust och effektiv implementering.
Vid en övergång från Unified CM till Webex Calling kan varje fas i PPDIO-processen dra avsevärt nytta av information som samlats in från den befintliga Unified CM-miljön. Till exempel kan omfattande inventeringar av användare, telefonnummer, samtalsfunktioner och komponenter för uppringningsplaner extraheras från den aktuella Unified CM-konfigurationen. Denna data kompletterar information som tillhandahålls direkt av intressenter och hjälper till att effektivisera planerings- och designaktiviteter. Att utnyttja lämpliga verktyg för att automatisera datautvinning och analys förbättrar inte bara noggrannheten utan accelererar också hela processen. Genom att använda insikter från den befintliga implementeringen kan övergången till Webex Calling genomföras mer effektivt än en traditionell nybyggd implementering, samtidigt som den strukturerade PPDIO-metoden följs. Denna process illustreras i figur Enhetlig CM-assisterad PPDIO-process.
Migrationsmetod
När du planerar din övergång från lokal Unified CM till Webex Calling måste du bestämma hur du ska gå tillväga. Först måste du bestämma om migreringen ska vara en snabbstegs (allt på en gång) eller en fasvis metod (migrera grupper av users/devices under en längre period).
Att göra en flash-cut migrering flyttar alla dina användare och enheter snabbast. Med den här metoden flyttar du alla användare och enheter från lokal Unified CM till Webex Calling samtidigt. I huvudsak är det ett enda migreringsfönster för alla användare och enheter. När migreringen är klar kommer alla dina användare och enheter att finnas på Webex Calling-plattformen och all din Unified CM-infrastruktur kan tas ur bruk. Många organisationer kan dock inte använda den här metoden på grund av omfattningen och storleken på deras samtalsdistribution.
Det andra tillvägagångssättet är en fasvis migrering. De flesta organisationer kommer att använda den här metoden eftersom den ger bättre kontroll, hantering och skalning vid migreringen. Den är också bättre lämpad för större UC-implementeringar and/or distributioner i flera regioner. Därför fokuserar detta dokument på den etappvisa metoden med två steg i övergången.
Som visas i figur nedanstående fasövergång: Hybrid och moln, den första övergångsfasen (fas 1) resulterar i en samexistensdistribution med dubbla anropsmiljöer. I den här fasen övergår vissa användare, enheter och mjukvaruklienter till Webex Calling medan andra fortfarande använder den lokala Unified CM-samtalskontrollen. Den sista övergångsfasen (fas 2) resulterar i en ren molnbaserad samtalsmiljö där alla användare, enheter och mjukvaruklienter har övergått helt till Webex Calling-plattformen.
Hur lång tid det tar för en organisation att helt övergå till molnsamtal varierar beroende på dess nuvarande implementering. I vissa fall kan en organisation göra den initiala övergången och stanna kvar i fasen med samexistens med dubbel samtalskontroll (fas 1) under en längre period (månader eller till och med år), medan en organisation i andra fall kan övergå helt till Webex Calling (fas 2) på mycket kort tid (veckor eller månader). Detta dokument är avsett att täcka båda faserna (fas 1 - samexistens och fas 2 - fullständig övergång).
Det är möjligt att vissa organisationer kan behålla en samexistens med dubbel samtalskontroll på obestämd tid utan planer på att någonsin helt övergå till molnsamtal.
Den andra faktorn är hur du ska överföra användare, enheter och mjukvaruklienter från den lokala samtalskontrollen till molnsamtalskontrollen. Den rekommenderade metoden är en 3-fasövergång. Figuren Rekommenderad 3-fasövergång nedan delar upp denna metod i 3 faser.
Före migrering: Den här fasen fokuserar på att förbereda både Webex- och Unified CM-miljöerna för migreringen. Detta handlar inte om specifik planering eller konfigurationer för samtal, utan fokuserar på att slutföra aktiviteter som kan göras nu och innan något Webex Calling-migreringsprojekt startar. Målet är att lägga grunden för de två miljöerna för att förbereda sig för migreringen.
Förberedelser för migrering: I den här fasen börjar arbetet med att förbereda migreringen till Webex Calling. Här behöver affärsmässiga och tekniska krav ses över och uppdateras. Gör inte bara en uppgradering av det som för närvarande används med Unified CM, utan omdefiniera istället de affärs- och tekniska krav som ditt företag behöver idag och i framtiden genom att utnyttja kraften i Webex Calling. Dessutom är det i detta skede du slutför din design, konfigurationsplanering och migrering. planning/schedule.
Migrering (utrullning och avveckling): I den här fasen sker den faktiska migreringen av användare, enheter, telefonnummer och mjukvaruklienter. Som diskuterats ovan kan denna fas slutföras för alla samtidigt (flash-cut) eller över flera ändringsfönster (phased-cut). Slutanvändarnas implementeringsplaner, utbildning och kommunikation är avgörande, så att dina användare är medvetna om ändringarna, hur de använder den nya samtalsplattformen och vet när ändringen kommer att ske. Det sista steget är att avveckla all lokal UC-infrastruktur som inte längre används.
Förmigreringsfasen innehåller aktiviteter (obligatoriska, rekommenderade och valfria) som du kan börja arbeta med omedelbart. Det rekommenderas att slutföra dessa snarare än senare och helst innan projektet påbörjas. Vissa aktiviteter kan ta längre tid att slutföra, därför kommer det att bidra till att effektivisera själva migreringsprojektet om du börjar dem tidigare.
Figuren Aktiviteter före migrering nedan belyser fem specifika kategorier av aktiviteter som är relaterade till en Webex Calling-migrering.
Förbered
Affärsmässiga och tekniska krav
När man planerar en migrering från till är det avgörande att noggrant samla in både tekniska och affärsmässiga krav under planeringsfasen. Det här steget säkerställer att migreringen är i linje med organisationens operativa mål och tekniska kapacitet, vilket minimerar risker och störningar.
Varför det är viktigt att samla in krav:
-
Samordnar affärsmål: Att förstå affärsbehoven hjälper till att skräddarsy migreringen för att stödja viktiga arbetsflöden, användarupplevelse och tillväxtplaner.
-
Säkerställer teknisk kompatibilitet: Att tidigt identifiera tekniska krav förhindrar integrationsproblem med befintlig infrastruktur, nätverk och slutpunkter.
-
Underlättar resursplanering: Tydliga krav hjälper till att uppskatta tidslinjer, kostnader och nödvändiga resurser korrekt.
-
Minskar risker: Tidig upptäckt av potentiella utmaningar möjliggör proaktiva lösningar, vilket minskar driftstopp och avbrott i tjänsten.
Företagskrav
Typiska affärskrav inkluderar:
-
Antal användare och platser som ska migreras
-
Önskade funktioner och tjänster (t.ex. samtalsdirigering, röstbrevlåda, konferenssamtal, automatiska svarstjänster, samtalsköer)
-
Efterlevnads- och säkerhetspolicyer
-
Budgetbegränsningar och kostnadsförväntningar
-
Behov av användarutbildning och support
-
Migreringstidslinje och överväganden gällande affärskontinuitet.
Att samla in önskade funktioner och tjänster är ett avgörande steg för att säkerställa att det nya systemet uppfyller affärsbehoven. När man samlar in dessa krav är det viktigt att inte bara beakta vad som för närvarande är konfigurerat, utan att försöka samla in de faktiska kraven från de affärsenheter som ska använda systemet. Annars finns det en risk att planen bygger på antaganden som inte är aktuella. Se till att utvärdera ytterligare eller förbättrade funktioner som finns i som kanske inte finns i , till exempel molnbaserade samtal, avancerade samtalsköer och . Detta hjälper till att utnyttja molnplattformens fulla fördelar.
När man utvärderar den nuvarande konfigurationen i är det viktigt att inse att inte alla befintliga inställningar kan förbli nödvändiga på grund av förändrade krav under systemets livscykel. Fokus bör ligga på att identifiera och behålla endast de konfigurationer som överensstämmer med driftsättningens nuvarande och framtida behov.
Fokusera mer på vad du behöver än vad du har.
Efterlevnads- och säkerhetspolicyer är viktiga överväganden under migreringen från Webex Calling för att säkerställa att det nya molnbaserade kommunikationssystemet följer juridiska, regulatoriska och organisatoriska standarder.
-
Regelefterlevnad: Organisationer måste verifiera att de uppfyller branschspecifika bestämmelser som GDPR, HIPAA eller SOX, vilka omfattar krav på dataskydd, lagring och hantering, samt landsspecifika krav relaterade till datalagring, avgiftsförbigång och medielokalitet.
-
Datasäkerhet: Säkerställa att röst- och signaldata krypteras både under överföring och i vila för att skydda mot avlyssning eller obehörig åtkomst.
-
Åtkomstkontroller: Definiera och tillämpa användarautentisering, auktorisering och rollbaserad åtkomst för att förhindra obehörig användning av kommunikationsresurser.
-
Revision och övervakning: Implementera loggnings- och övervakningsfunktioner för att spåra åtkomst och användning för efterlevnadsrevisioner och utredningar av säkerhetsincidenter.
-
Policyanpassning: Anpassa migreringen till befintliga företagssäkerhetspolicyer, inklusive slutpunktssäkerhet, nätverkssegmentering och incidenthanteringsplaner.
-
Leverantörens säkerhetsgaranti: Utvärdera Ciscos säkerhetscertifieringar och efterlevnadsintyg för att säkerställa tillförlitlighet.
Att hantera dessa efterlevnads- och säkerhetspolicyer under planeringsfasen hjälper till att minska risker, undvika rättsliga påföljder och upprätthålla integriteten och sekretessen i kommunikationen under och efter migreringen.
Användarutbildning och supportbehov är viktiga komponenter under migreringen från till för att säkerställa en smidig övergång och användarimplementering. Viktiga överväganden inkluderar:
-
Träningsprogram: Utveckla skräddarsydda utbildningar för olika användargrupper (slutanvändare, administratörer, helpdeskpersonal) för att bekanta dem med funktioner, användargränssnitt och nya arbetsflöden.
-
Dokumentation: Tillhandahåll tydliga och lättillgängliga användarhandböcker, vanliga frågor och svar samt snabbreferensmaterial, inklusive Nyheter och skillnader resurser och steg-för-steg Före- och efterguider (i video- eller snabbguideformat), för att stödja användarna när de anpassar sig till den uppdaterade upplevelsen efter migreringen.
-
Förändringshantering: Kommunicera förändringar proaktivt för att hantera användarnas förväntningar och minska motstånd.
-
Stödstruktur: Upprätta ett dedikerat supportteam eller en eskaleringsväg för att snabbt åtgärda användarproblem under och efter migreringen.
-
Fortlöpande utbildning: Planera för kontinuerliga utbildningsuppdateringar allt eftersom nya funktioner eller uppdateringar släpps i .
-
Återkopplingsmekanismer: Implementera kanaler för användare att rapportera problem och ge feedback för att förbättra utbildnings- och supportprocesser.
Att ta itu med dessa utbildnings- och supportbehov under planeringsfasen hjälper till att minimera störningar, öka användarnas förtroende och maximera fördelarna med att migrera till .
Tekniska krav
Flera viktiga tekniska krav måste samlas in och dokumenteras för en lyckad migrering från till , inklusive detaljer för:
-
Nätverksberedskap och bandbreddskapacitet
En omfattande nätverksbedömning är avgörande för att säkerställa att din befintliga infrastruktur kan stödja den nya Webex Calling-miljön. Detta inkluderar:
-
Bandbreddsanalys: Utvärdera nuvarande och förväntad bandbreddsanvändning för att hantera röst-, video- och datatrafik utan överbelastning.
-
Tjänstekvalitet (QoS): Implementera QoS-policyer för att prioritera rösttrafik och minimera latens, jitter och paketförlust.
-
WAN- och internetanslutning: Verifiera att WAN-länkar och internetanslutningar uppfyller kraven för molnbaserade samtal, inklusive redundans- och redundansfunktioner.
-
Brandvägg och NAT-konfiguration: Säkerställa att brandvägg och NAT-inställningar tillåter nödvändig signalering och medietrafik för .
-
-
Integration med befintligt system
Sömlös integration med befintliga affärssystem är avgörande för användarupplevelse och kontinuitet i arbetsflödet:
-
Katalogtjänster: Utvärdering av integration med en företagskatalog för automatiserad användarprovisionering och autentisering.
-
CRM- och affärsapplikationer: Identifiera integrationspunkter med CRM-system och andra affärskritiska applikationer.
-
Äldre PBX-interoperabilitet: Planering för samexistens eller etappvis migreringsstrategier om några äldre telefonisystem kommer att finnas kvar under övergången.
-
-
Slutpunktskompatibilitet och provisionering
Alla slutpunkter inklusive bordstelefoner, datortelefoner och mobila enheter bör utvärderas för kompatibilitet:
-
Enhetsstöd: Bekräfta att befintliga IP-telefoner och enheter stöds av eller identifiera nödvändiga ersättningar.
-
Provisioneringsprocesser: Etablera automatiserade eller effektiva provisioneringsmetoder för effektiv onboarding av endpoints.
-
Uppdateringar av firmware och programvara: Planering för nödvändiga uppdateringar för att säkerställa interoperabilitet och säkerhet.
-
-
Säkerhetskonfigurationer och krypteringsstandarder
Säkerhet är av största vikt inom molnkommunikation:
-
Kryptering: Tillämpa end-to-end-kryptering för signalering och medieströmmar, i linje med Ciscos bästa säkerhetspraxis.
-
Autentisering och åtkomstkontroll: Implementera säkra autentiseringsmekanismer (som SSO, multifaktorautentisering) och detaljerade användaråtkomstkontroller.
-
Efterlevnad: Säkerställa att lösningen uppfyller relevanta regelverk och branschstandarder (t.ex. GDPR, HIPAA).
-
Säkerhetsövervakning: Integrering med SIEM-verktyg och konfigurering av aviseringar för potentiella säkerhetsincidenter.
-
| Krav | Viktiga överväganden |
|---|---|
| Nätverksberedskap och bandbredd | Bandbredd, QoS, WAN/Internet, Firewall/NAT |
| Integration med befintliga system | Katalog, CRM, PBX, Email/Calendar |
| Slutpunktskompatibilitet och provisionering | Enhetssupport, provisionering, firmwareuppdateringar |
| Säkerhetskonfigurationer och kryptering | Kryptering, autentisering, efterlevnad, säkerhetsövervakning |
| Användarutbildning och förändringsledning | Utbildningsprogram, dokumentation, förändringskommunikation |
| Nummerportabilitet och uppringningsplan | Antal migration/porting, översättning av uppringningsplan |
| Tredjepartsintegrationer | Personsökare, kontaktcenter, fax, analoga enheter |
Nätverksberedskap och krav
Nätverksberedskap är avgörande för en lyckad migrering till alla molnbaserade samtalslösningar som . Dålig nätverksplanering kan leda till försämrad samtalskvalitet, tappade samtal och missnöjda användare. Kunder måste göra en nätverksbedömning innan de migrerar till . Det rekommenderas att bekräfta tillgängligheten av nätverksbandbredd för förväntad samtalsvolym, säkerställa att kraven på tjänstekvalitet (QoS) är uppfyllda och förstå de olika portar som måste öppnas i edge-brandväggen/brandväggarna.
Tillförlitlig nätverksanslutning med tillräcklig servicekvalitet (bandbredd, paketförlust, RTT) är ett grundläggande krav för att säkerställa bästa möjliga användarupplevelse från början till slut för alla röst- och videokompatibla slutpunkter, klienter och applikationer som använder .
Kunder och partners har tillgång till anslutningsalternativ utöver Over-the-top (OTT) Internet som kan optimera anslutningen till att inkludera Webex Edge Connect. För mer information om Webex Edge Connect-designdetaljer, se Cisco Preferred Architecture för Webex Edge Connect för Webex Meetings, Calling Multi-Tenant och Dedicated Instance.
Kunder kan använda CScan för nätverksbedömning, vilket ger information om kundens nätverkskvalitet, hur många samtal som kan upprättas, latens och så vidare. För mer information om CScan-verktyget, se Använd CScan för att testa Webex Calling-nätverkskvaliteten.
För att säkerställa att nätverket är redo för migrering till , följ följande checklista:
-
Bandbreddsplanering
Beräkna samtidiga samtal per plats för att säkerställa att du har tillräckligt med bandbredd uppströms och nedströms och inkludera utrymme för annan affärskritisk trafik och framtida tillväxt.
Tabellen Webex Calling bandbredds beräkningar visar de samtalstyper som är tillgängliga med en distribution tillsammans med codec och maximal bandbredd som krävs för varje samtalstyp. Som visas i tabellen Webex Calling bandbreddsberäkningar för samtalstyp kan den erforderliga ljudbandbredden för varje samtalstyp beräknas med följande allmänna formel:
Antal förväntade samtidiga samtal * Bandbredd per samtal baserat på codec = Nödvändig nätverksdataflöde.
Tabell 2. Webex Calling bandbreddsberäkningar för samtalstyp Samtalstyper Codec - bandbredd Bandbreddsberäkningar / Bordstelefon -> OPUS - 70 kbps Antal samtidiga samtal * 70 kbps = Nödvändig nätverksgenomströmning / Bordstelefon -> Bordstelefon OPUS – 70 kbps Antal samtidiga samtal * 70 kbps = Nödvändig nätverksgenomströmning / Bordstelefon -> PSTN via LGW G.711 – 80 kbps Antal samtidiga samtal * 80 kbps = Nödvändig nätverksgenomströmning / Bordstelefon -> PSTN via molnbaserad PSTN (t.ex. Cisco-samtalsplan) G.711 – 80 kbps Antal samtidiga samtal * 80 kbps = Nödvändig nätverksgenomströmning / Bordstelefon -> Företag via LGW G.722 – 80 kbps Antal samtidiga samtal * 80 kbps = Nödvändig nätverksgenomströmning / Bordstelefon -> röstbrevlåda OPUS – 70 kbps Antal samtidiga samtal * 70 kbps = Nödvändig nätverksgenomströmning Genom att summera den samtidiga erforderliga nätverksgenomströmningen per samtalstyp kan det totala potentiella bandbreddskravet för en specifik plats bestämmas.
Alla samtalsben är alltid förankrade på åtkomst-SBC:erna. För att bestämma den erforderliga internetbandbredden för en given plats behöver inte bara samtal mellan platser beaktas, utan även samtal inom platsen och samtal till och från en lokal gateway på den platsen. Till exempel skulle ett samtal inom en plats mellan två MPP-telefoner behöva upp till 2 x 70 kbps full duplex på platsens internetåtkomst.
Tabellen Exempel på bandbredds beräkning för Webex-samtal visar ett exempel på en komplett bandbredds beräkningsövning, förutsatt att alla enheter finns på samma plats.
Tabell 3. Exempel på bandbreddsberäkning för Webex-samtal Samtalstyper Antal samtidiga samtal Total bandbredd Webex-appen / Bordstelefon → Webex-app 15 2 * 15 * 70 kbps = 2 100 kbit/s Webex-appen / Bordstelefon → Bordstelefon 15 2 * 15 * 70 kbps = 2 100 kbit/s Webex-appen / Bordstelefon → PSTN via LGW 50 2 * 50 * 80 kbps = 8 000 kbit/s Webex-appen / Bordstelefon → PSTN via Cloud Connect för Webex Calling 0 0 * 80 kbit/s Webex-appen / Bordstelefon → Företag via LGW 15 2 * 15 * 80 kbps = 2 400 kbit/s Webex-appen / Bordstelefon → Webex Calling Röstbrevlåda 5 5 * 70 kbps = 350 kbps Totalt antal samtal / Bandbredd 100 samtal 14 950 kbit/s / 14,95 Mbit/s -
Alla bandbreddsvärden i tabellerna ovan avser IP-bandbredd. Länkbandbredden är högre beroende på WAN-inkapslingar.
-
Bandbredden i tabellerna ovan är för ljudsamtal. För bandbredd för videosamtal, Webex-appen och MPP 8845/65 Telefoner stöder H.264-video med maximal upplösning på 720p och en maximal bandbredd på 1 500 kbps per samtal. Emellertid kommer mängden bandbredd som förbrukas vid någon tidpunkt under samtalet att variera baserat på den variabla bithastigheten som är inneboende i videokommunikation.
-
-
Tjänstekvalitet (QoS)
Implementera QoS-policyer i din lokala miljö för att prioritera realtidstrafik och säkerställa att QoS upprätthålls över switchar, routrar och brandväggar.
-
Mål för latens, jitter och paketförlust
Följande tröskelvärden rekommenderas för optimal röstkvalitet när samtal går över internet (Over-the-Top, OTT):
-
Latens - mindre än 100 ms enkelriktad
-
Jitter - mindre än 10 ms
-
Paketförlust - 0,5 % eller mindre.
-
-
Brandvägg och NAT
Se till att brandväggen är konfigurerad för att tillåta trafik enligt vad som anges i artikeln som finns på Portreferensinformation för Webex Calling. Tillåt dessutom åtkomst till domäner och IP-intervall som listas i samma guide och undvik SIP ALG eftersom det stör SIP-signaleringen. Medietrafik via proxyservrar bör undvikas.
-
DNS och NTP
Säkerställ korrekt DNS-upplösning för domäner och pålitliga NTP-servrar för att synkronisera enhetsklockor för TLS-certifikatverifiering och loggning.
-
Planering av redundansväxling
Överväg befintliga leverantörers dataanslutningar (MPLS, SD-WAN osv.) och planera generellt för direkt internetåtkomst på varje plats i din distribution. Planera för redundanta internetlänkar där hög tillgänglighet krävs. Eftersom du kommer att använda molnbaserade tjänster är en pålitlig internetanslutning med tillräcklig bandbredd ett grundläggande krav. Du bör ompröva att göra denna övergång om din organisations internetanslutning(ar) generellt sett inte är tillförlitlig(a) med låg latens och tillräcklig dataöverföringshastighet uppåt och nedåt.
-
Platsens överlevnadsförmåga
Webbplatsens överlevnadsförmåga säkerställer att ditt företag alltid är nåbart, även om din nätverksanslutning skulle brytas. Site Survivability använder en gateway i ditt lokala nätverk för att tillhandahålla en reservtjänst för anrop till slutpunkter på plats i situationer där nätverksanslutningen bryts. Överväg platsens överlevnadsförmåga med en lokal överlevnadsgateway (SGW) om affärskrav kräver kontinuerliga samtal vid nätverksavbrott. För mer information om kontroll av webbplatsens överlevnadsförmåga, se Webbplatsens överlevnadsförmåga för Webex Calling.
Konfigurera molnansluten UC
Cloud Connected UC (CCUC) är en molnbaserad hanterings- och analyslösning utformad för att ge centraliserad insyn, administration och insikter för distributioner både lokalt (som Unified CM) och i molnet (). Det fungerar som en brygga mellan traditionella lokala miljöer och Ciscos molntjänster, och stödjer organisationer under hela migreringsprocessen från till .
Under övergången till spelar CCUC en viktig roll i att effektivisera migreringsprocessen genom att underlätta insamlingen av omfattande data från den befintliga Unified Communications-distributionen. CCUC hjälper till med viktiga övergångsuppgifter som att migrera enheter, funktioner och användarkontakter, samt automatisera firmwareuppdateringar för IP-telefoner som stöds. Genom att tillhandahålla centraliserad insyn och hantering bidrar CCUC till en smidigare och effektivare migreringsupplevelse.
Cisco rekommenderar starkt att CCUC driftsätts tidigt i övergångsprojektet, helst före eller under förberedelsefasen. Detta kommer att möjliggöra de insikter och funktioner som behövs för att noggrant bedöma, inventera och planera för efterföljande migreringsaktiviteter och för att påbörja din resa mot framtida hybridfunktioner.
Bedömning av den nuvarande miljön
En viktig aktivitet i planeringen av din migrering är att utvärdera den nuvarande lokala miljön och distributionen. Detta ger insikter i vilka potentiella förändringar som kan krävas för en framgångsrik övergång till . Det låter dig också bedöma plattformens viktigaste element i jämförelse med den befintliga lokala distributionen. Du kan använda den här informationen för att identifiera vilka specifika uppgifter som krävs för övergången och vilka förändringar du vill göra för att uppfylla dina affärs- och tekniska krav samt användningsfall.
Följande aspekter är viktiga att granska som en del av detta arbete.
Licensiering
Att förstå den nuvarande licensstrukturen för den befintliga distributionen är avgörande när man förbereder sig för att migrera till . Utför en licensbedömning av följande områden i din befintliga lokala Cisco-lösning.
-
Plattform
Förmågan att fullt ut formulera vad som för närvarande är licensierat på din kärnplattform kommer att vara avgörande när du arbetar med ditt kontoteam eller din partner för att fastställa den bästa vägen till flexibel licensiering. är licensierad med flexibel licensiering. För mer information om flexlicenser, se Cisco Collaboration Flex Plan.
-
Användare och enheter
Identifiera vilken licenskategori dina befintliga användare och enheter kräver. Detta kommer att användas för att avgöra vilken typ av licens som krävs för användarna och enheterna. erbjuder flera licenstyper, inklusive professionella och standardlicenser för användare och professionella och gemensamma områdeslicenser för arbetsytor. För mer information om enhetslicensiering, se databladet som finns tillgängligt på Enhetslicensiering.
-
Lokal gateway
Om Cisco Unified Border Element (CUBE) krävs för PSTN-åtkomst vid denna övergång måste även CUBE-licensiering övervägas. Att tänka på gällande CUBE-licenser behandlas senare i det här dokumentet.
Locations/Sites
Antalet och typerna av platser (stora centrala, regionala, filialer och så vidare) inom din befintliga distribution bör beaktas när du planerar denna övergång. En fullständig förståelse av de befintliga driftsättningsplatserna kommer att hjälpa till med strategisk planering för en lyckad övergång, särskilt när det gäller att bestämma vilka platser som ska migreras och i vilken ordning. Att i detalj förstå kraven för uppringningsplaner (nummer, uppringningsvanor, begränsningsklasser och så vidare), platsens nätverksanslutning och bandbredd (internet, WAN, LAN) och PSTN-åtkomst (lokal eller centraliserad, IP eller TDM) för varje plats kommer att vara avgörande när man fattar migreringsbeslut. För mer information om vanliga distributionsmodeller och viktiga överväganden, se informationen om distributionsmodeller för samarbete som finns i Collaboration SRND.
En annan viktig faktor att beakta vid övergången till är platstillgänglighet. har olika funktioner, prenumerationer och enheter som är tillgängliga beroende på var din distribution finns. För mer information om geografisk tillgänglighet, se Var är Webex tillgängligt?.
Slutligen är det viktigt att förstå vilken inverkan övergången till kommer att ha på andra samarbetstjänster. Baserat på syftet med detta dokument är det allmänna antagandet att om befintliga samarbetstjänster utanför den anropande arbetsbelastningen ska bibehållas, förväntas en övergång till den ovan nämnda hybriddistributionen i fas 1. Exempel på samarbetstjänster som kan kräva hybriddistribution inkluderar lokala kontaktcenter som ännu inte har migrerats till Webex kontaktcenter och täta integrationer med system som personsökarsystem och fakturering. För mer information om övergången av ytterligare samarbetsarbetsbelastningar och tjänster, se Samarbetsövergångar.
Befintligt lager devices/clients
Innan övergången påbörjas är det viktigt att inventera dina befintliga hårdvaru- och mjukvaruslutpunkter. Att ha en komplett lista över enheter types/models, Hårdvaruversioner, typer av mjukvaruklienters operativsystem och kvantiteter säkerställer att du kan planera övergången av enheterna på ett adekvat sätt och mildra effekterna för de enheter som inte kan migreras till molnsamtal. Inventeringen bör användas för att fastställa vilka enheter som ska övergå och vilka enheter som ska ersättas före övergången.
Bordstelefoner
För bordstelefoner med ljud och video stöds endast bordstelefonerna i 6800-, 7800-, 8800- och 9800-serien. Detta är en delmängd av Cisco IP-telefoner som stöds med . Det finns vissa modeller och versioner av 6800-, 7800- och 8800-telefonerna som inte kan användas med . För mer information om vilka modeller och hårdvaruversioner som stöds, se Enheter som stöds för Webex Calling.
Cisco 6800-seriens IP-telefoner kan inte uppgraderas från Enterprise-firmware till Multiplatform (MPP) firmware, vilket krävs för . Därför måste alla 6800-telefoner som är registrerade för att köra företagsfirmware ersättas med en 6800 MPP-modell eller med en annan telefonmodell som stöds.
Cisco IP-telefoner i 7800- och 8800-serien måste uppgraderas till MPP-firmware (Multiplatform Phone) innan övergången och registreringen av dem görs. För att avgöra vilka 7800- och 8800-modeller och hårdvaruversioner som stöder MPP-firmware, se Konvertera Cisco 7800- och 8800-seriens IP-telefoner mellan Enterprise- och MPP-firmware.
8845, 8865 och 8865NR har nått slutet av försäljningstiden och rekommenderas inte att migreras till .
Äldre versioner av 8800-seriens telefoner (8811, 8841, 8851, 8851NR, 8861) rekommenderas inte att användas med Webex Calling. Telefoner med hårdvaruversioner VID 14 eller tidigare kommer att registreras men kan uppleva vissa prestandaproblem på grund av hårdvaran.
Bordstelefonerna i 9800-serien kör PhoneOS, som stöder både och registrering. Därför kan dessa telefoner övergå till utan en firmware-uppgradering.
Alla andra IP-telefoner måste ersättas med telefoner i 6800-, 7800-, 8800- eller 9800-serien som stöds av Webex Calling. För mer information om vilka IP- och bordstelefoner som stöds med [] finns i artikeln på Enheter som stöds för Webex Calling.
Videoslutpunkter
Personliga och rumsbaserade videoslutpunkter, inklusive Cisco Board-serien, Room-serien och Desk-serien, kan direkt SIP-registreras till . Någon av dessa slutpunkter som behöver skapa ljud and/or PSTN-samtal kräver en samtalslicens:
-
Delade enheter i konferensrum, mötesutrymmen etc. kräver antingen en Professional Workspace- eller Workspace-licens.
-
En slutanvändares personliga enhet kräver en professionell eller standardlicens.
Bestäm hur många videoslutpunkter som är registrerade för och används för att ringa ljudsamtal. Det är möjligt att vissa videoslutpunkter endast används för att delta i möten eller ringa SIP-videosamtal. I båda fallen måste slutpunkterna fortfarande migreras innan servrarna tas ur drift, men detta kommer att hjälpa till att avgöra hur många av dem som kommer att behöva licenser för att fortsätta ringa telefonsamtal.
-
När videoenheter flyttas från registrering till , kommer URI:n för dessa slutpunkter att ändras eftersom de nu är molnregistrerade.
-
Telefonmodellerna 8845, 8865 och 8875 är personliga videotelefoner som stöds med .
Mjuka klienter
är den enda mjukvaruklienten som stöds av , till skillnad från Unified CM som stöder både Webex-appen och Jabber, och är den nya standardmjukvaruklienten för slutanvändare.
Beroende på vilket/vilka distributionslägen som implementerats för Jabber (endast snabbmeddelanden, endast telefon, and/or fullständiga UC-lägen), kan du också behöva överväga övergången av Meddelanden and/or Mötesarbetsbelastningar från Jabber till . Den kan distribueras i endast telefonläge om den ska användas som en klient för endast samtal eller den kan distribueras som fullständig Webex Suite om andra arbetsbelastningar, t.ex. Webex Messaging, används. and/or Webex Meetings överförs till appen med samtal.
Det förbättrar slutanvändarens upplevelse genom att tillhandahålla AI-funktioner som audio/video intelligens, samtalstranskription och annat. Det finns mer information i https://www.webex.com/all-new-webex.
Innan användare flyttas till dig måste de överföra deras Jabber-klienter till . Du har två alternativ för att slutföra denna övergång.
-
Innan du överför dem till
-
När du övergår till dem.
För att underlätta den initiala övergången till , rekommenderas att använda alternativ 1 och flytta användare till med anropande först. Detta ger användarna tid att bekanta sig med den nya applikationen medan de fortfarande använder den befintliga lokala samtalsplattformen. När du är redo att flytta användare till , konfigurerar du deras registrering med molnsamtalsplattformen.
För mer information om dessa två alternativ, se Migreringsresa - ett eller två steg?.
För en komplett lista över enheter som stöds för Enheter som stöds för Webex Calling.
Verifiera enhetens behörighet
Som tidigare nämnts stöder den en delmängd av Cisco IP-telefoner och kräver en annan typ av firmware för telefoner i 7800- och 8800-serien. Unified CM-telefoner kör Enterprise-firmware medan telefoner kör Multiplatform Phone (MPP)-firmware. Det rekommenderas att kontrollera vilka registrerade telefoner som är berättigade att uppgradera till MPP-firmware under förberedelsefasen. Detta ger dig tid att ersätta icke-godkända telefoner med en av de telefonmodeller som stöds eller att identifiera ett alternativt abonnemang, som att flytta en användare till endast Webex-appen.
För att hjälpa till att avgöra telefonernas behörighet har Control Hub ett inbyggt verktyg som heter Migrera din telefon till Webex Calling. När du använder det här verktyget för att kontrollera enhetsberättigande, välj migreringsalternativet Generera endast enhetslicens.
Det här alternativet låter dig ladda upp en CSV-fil som innehåller telefonerna så att du kan kontrollera varje telefons behörighet. Genom att välja det här migreringsalternativet läggs inte telefonerna till eftersom du fortfarande är i förberedelsefasen och inte är redo att göra detta än. Mer information finns i Migrera din telefon till Webex Calling .
Det är möjligt att vissa telefoner kan komma tillbaka med en Okänd behörighet. Detta beror vanligtvis på att det inte går att validera viss information om telefonen i backend-systemet. För telefoner som har statusen Okänd har du två alternativ för att kontrollera om de är berättigade att uppgradera till MPP-firmware.
-
Kontrollera varje telefon manuellt och verifiera modell och hårdvaruversion (PID VID)
7800/8800 telefonetikett med information om modell och hårdvaruversion -
Använd Cisco IP-telefonberedskapsverktyget
Ladda ner verktyget från https://github.com/joemar2/mpp_readiness_check.
Det här verktyget är inte ett officiellt Cisco-verktyg och det stöds inte heller av TAC. Den har support efter bästa förmåga men är gratis att använda.
Det här verktyget måste köras på en dator som är lokal och har åtkomst till servrarna och IP-telefonerna. Den har ett alternativ för att aktivera webbåtkomst på IP-telefonerna, vilket rekommenderas och behövs för att få bästa resultat. Därför bör den användas under lågtid för att undvika störningar för slutanvändarna. Verktygets utdata ger en rapport som listar vilka av 7800- och 8800-serietelefonerna som är berättigade att uppgradera till MPP-firmware. Eftersom den har direkt åtkomst till telefonen kan den verifiera de okända enheter som rapporterades från Control Hub-verktyget.
Rapport om verktyget för beredskap för Cisco IP-telefoner
Användare
Ett av de viktigaste förberedelsestegen för att säkerställa en lyckad migrering är korrekt användarprovisionering. Du måste planera ordentligt för alla användare även om du gör en stegvis migrering. Användare måste vara konfigurerade för något av följande:
-
Distribuera med anrop
-
Distribuera med
-
Konfigurera tjänster för en användare
-
För att göra användare sökbara i katalogen (klicka för att ringa, användarkontaktinformation, sökning i telefonkatalogen).
Det rekommenderas att du etablerar alla användare före eller i början av projektet. Detta inkluderar användare som fortfarande använder Unified CM för sin samtalsplattform som är oberoende av deras samtalsenhet (IP-telefon, Jabber, ). Allt eftersom användare migreras till (and/or den ) kommer du att uppdatera deras licenser för att aktivera de tjänster de behöver. Genom att etablera alla företagsanvändare som ringer innan övergången påbörjas, kan en användare som har övergått till eller söka i katalogen efter en företagsanvändare som fortfarande använder Jabber. and/or på . Detta säkerställer att övergångsanvändare kan hitta andra användares kontaktinformation och ringa till dem med hjälp av katalogsökningen.
Figuren katalogsökning visar ett exempel på en användare som söker efter en annan användare. Sökresultaten visar användarens kontaktinformation och kan gälla en användare som fortfarande är på Jabber och/eller en användare som har övergått till and/or .
Bestäm sedan vilka av de befintliga lokala anropande användarna som ska överföras till . Om alla eller ett stort antal användare ska överföras rekommenderas det att flytta användarna i grupper för att säkerställa att projektteamet, IT-personalen och supportpersonalen kan hantera övergången och eventuella problem som kan uppstå. Du bör också avsätta tid för att ge inledande information och utbildningstillfällen för att förbereda användarna för denna övergång. Gruppering av användarövergångar kan göras baserat på en mängd olika kriterier, inklusive platsen eller anläggningen som användarna är tilldelade, användarnas avdelningar eller till och med användartyper (kunskapsarbetare, chefer, mobila arbetare och så vidare).
Om användare i distributionen till exempel är uppdelade på tre huvudplatser, New York (NYC), San Francisco (SFC) och Research Triangle Park (RTP), kan en användarövergångsplan se ut som den plan som beskrivs i tabellen Användarövergångsplan per plats.
| Användarwebbplats / plats | Information och utbildningar inför övergången | Övergångstid | Stöd efter övergången |
|---|---|---|---|
| New York (1 525 användare) | Vecka 1 april | 15 april – 27 april | Vecka 29 april |
| SFO (1 600 användare) | Vecka 6 maj | 20 maj – 31 maj | Vecka 3 juni |
| RTP (1 275 användare) | Vecka 3 juni | 17 juni – 28 juni | Vecka 1 juli |
En annan viktig faktor är att överföra användare som har beroenden mellan varandra. Detta kan inkludera men är inte begränsat till följande:
-
BLF-övervakning
-
Samma jakt pilot/group
-
Dela linjer
-
Del av samma svarsgrupp
-
Använda samma samtalsparkeringsnummer
-
Snabbtelefon
-
Admin/Exec.
Du kan granska konfigurationen (GUI eller export) eller använda verktyget Migration Insights för att identifiera användargrupperna med dessa beroenden.
PSTN-anslutning
kan komma åt PSTN på tre sätt: Cisco-samtalsplaner, Cloud Connect för (tidigare Cloud Connected PSTN) och lokal PSTN (lokal gateway). En enda plats som definieras inom kan dock bara tilldelas ett enda PSTN-alternativ.
Lokalt PSTN med en lokal gateway (LGW) är en viktig del av övergångsstrategin. Det ger anslutning mellan den lokala distributionen and/or PSTN och plattformen stöder både Cisco och certifierade tredjepartssessionsgränskontroller (SBC) som kan användas som lokal gateway. För den senaste listan över SBC:er som stöds, se Lista över SBC:er som stöds.
stöder upp till 250 samtidiga samtal från en enda lokal gateway som är registreringsbaserad och mer än 250 samtidiga samtal från en enda lokal gateway som är certifikatbaserad. Certifikatbaserade lokala gateways kan stödja upp till 6500 samtidiga samtal, men detta baseras på vilken typ av anslutning den lokala gatewayen har (Over-the-Top kontra interconnect-peering) och SBC-modellen som den lokala gatewayen är distribuerad på. Dessa gränser är i huvudsak standardantalgränsen för både lokala gateway-baserade PSTN-samtal och samtal mellan platser mellan och slutpunkter. För mer information, se Kom igång med lokal gateway.
Alla samtal som överskrider denna gräns avvisas med felet 403 Forbidden. Kommandot show call active voice kan köras på den lokala gatewayen när som helst för att fastställa det totala antalet aktiva samtal.
Dåliga nätverksförhållanden mellan en lokal gateway och åtkomst-SBC:n kan begränsa signaleringsanslutningens prestanda, vilket leder till en ännu lägre gräns för samtidiga samtal. Enkelriktad latens mellan den lokala gatewayen och datacentret bör inte överstiga 100 ms och jitter bör vara mindre än 10 ms medan paketförlusten är mindre än 0,5 ms. %.
Drag & funktionsanvändning
Vid bedömning av den nuvarande miljön är det viktigt att identifiera och granska vilka funktioner som är konfigurerade. Dessutom är det viktigt att förstå användningen av funktionerna så att du kan (om)definiera dina affärs- och tekniska krav för din implementering.
För att avgöra vilka funktioner som är konfigurerade, analysera konfigurationen. Detta är all statisk data som ställs in när en funktion eller inställning konfigureras i systemet. Följande alternativ kan användas för att slutföra denna analys:
-
Granska konfigurationen i administratörsgränssnittet
-
konfigurationsexport -- bulkexport eller AXL
-
Verktyg för migreringsinsikter (rekommenderas)
-
Ciscos verktyg från tredjepartspartners (rekommenderas).
För att effektivt analysera funktionsutnyttjande är det viktigt att undersöka dynamiska systemdata som användning, registreringar och samtalsaktivitet. Olika analysverktyg och dashboards ger insikter i dessa mätvärden, vilket möjliggör en omfattande förståelse av systemets prestanda och kapacitet, vilket stöder välgrundade beslutsfattande under migrerings- och optimeringsarbetet. Följande alternativ kan användas för att slutföra den här typen av analys:
-
Granskning av råa CDR-poster
-
Granskning av Unified CM RTMT-data
-
Migration Insights-verktyget med CDR-data
-
Granskning av molnansluten UC-analys i
-
Samtalsvolym
-
Registrerade slutpunkter
-
(CAC) platser
-
Utnyttjande av bagageutrymmet.
-
-
Ciscos verktyg från tredjepartspartners.
Cisco rekommenderar att man börjar med Webex Control Hub Migration Insights-verktyget för den här analysen. Du importerar din exporterade .TAR-fil och Unified CM CDR-filerna (valfritt men krävs för analys av funktionsutnyttjande) till verktyget. Verktyget genererar följande CSV-baserade rapporter som kan användas för att starta analysen:
| Rapportnamn Rapportbeskrivning |
|---|
| ImportedDataBulk.csv Alla användare och enheter från Unified CM-data |
| DeviceEligibility.csv Identifierar enheter som är berättigade att migrera till Webex Calling (IP-telefoner, rums-OS-enheter, ATA:er och tredjepartsenheter) |
| DevicePoolNumbers.txt Lista över alla nummer i en viss enhetspool |
| HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv Detaljer om enheter och användare som ska migreras tillsammans baserat på delade linjer, Hunt Pilot, samtalskö, samtalsparkering och gruppkonfiguration för samtalshämtning |
| HuntGroupMigrationInsight.csv Detaljerad information om tilldelade jaktlinjer, linjegrupper och tillhörande agenter |
| SharedlineGroupMigrationReport.csv Översikt över hur telefonnummer (katalognummer) delas mellan användare |
| Rapportnamn Rapportbeskrivning |
|---|
| FeatureUsageBasedDeviceEligibilityReport.csv Information om behörighet för enhetsmigrering baserat på funktionsanvändning |
| FeatureUsageWithLastUsageDateReport.csv Användningsräkning för antalet gånger som huntpilot(er) och samtalskö(er) har anropats tillsammans med det senaste användningsdatumet |
| UserWorkspaceLastUsage.csv Sista användningsdatum för användare och arbetsytor för både mjukvaruklienter och hårdvarutelefoner |
| DIDUsageReport.csv DID-användning för både tilldelade och otilldelade DID:er |
För mer information om rapporterna Migrationsinsikter, se Migrationsinsikter.
Om du behöver mer information om funktionerna och användningen efter att ha granskat informationen i Migration Insights-rapporterna rekommenderar Cisco att du överväger ett av Ciscos migreringsverktyg från tredjepartspartners. and/or för att granska konfigurationerna i det grafiska användargränssnittet eller i konfigurationsexportdata.
Cisco-integrationer: Unity Connection UCCX UCCE
Röstbrevlådan är en integrerad del av erbjudandet och inbyggd i lösningen. Den kan inte integreras med en lokalbaserad röstbrevlåda som Unity Connection eller Unity Connection Express. Vidare finns det inget inbyggt sätt att migrera befintliga röstmeddelanden eller hälsningar från Unity-anslutningen till den inbyggda röstbrevlådans tjänst som är tillgänglig med . Vissa av Ciscos migreringsverktyg från tredjepartspartners har funktioner för att migrera en del av dessa data. För mer information om röstbrevlåda för , se Konfigurera och hantera röstbrevlådans inställningar för en Webex Calling-användare.
stöder även delade röstbrevlåda och faxbrevlådor. För mer information, se Hantera en delad röstbrevlåda och inkommande faxlåda för Webex Calling.
har en inbyggd funktion för automatisk svarstjänst som ingår som en del av kärnplattformen. Den här funktionen möjliggör övergång av din Unity Connections samtalshanterare och automatiska svarsfunktioner. Control Hub-verktyget, Migrera funktioner från Unified CM, stöder migrering av Unity Connection-konfigurationer till automatiska svarsfunktioner. För mer information om hur du använder det här verktyget, se Migrering av enheter och funktioner från Unified CM till Webex Calling.
Samtalsinspelning
inkluderar två alternativ för samtalsinspelning utan extra kostnad.
-
Webex-samtalinspelning
-
Dubber Go-inspelning (partnererbjudande) - en integration mellan och Dubber där all inspelad media säkert förvaras i molnet.
inkluderade inspelningsalternativ tabellen visar några viktiga funktioner hos de två samtalsinspelningsalternativen som är tillgängliga utan extra kostnad.
| Webex | Dubber Go |
|---|---|
| Tillgänglig för alla användare | Tillgänglig för alla användare |
| Obegränsade inspelningar | Obegränsade inspelningar |
| 1 års lagringsperiod* | 30 dagars lagringsperiod |
| 100 GB lagringsutrymme per organisation | - |
| Regelefterlevnadsansvariga kan komma åt och hantera samtalsinspelningar | - |
| API:er för att hantera inspelningar | - |
Administratörer kan konfigurera och hantera användarnas åtkomst till sina samtalsinspelningar
|
Endast användare kan komma åt och hantera sina inspelningar
|
Om din organisation behöver ytterligare inspelningsfunktioner, som inspelning av samtal om efterlevnad, längre lagringsperioder, mer lagring, AI-analys, and/or administratörsåtkomst, betalda erbjudanden eller tillägg finns från både Cisco och tredjepartsleverantörer av inspelningar. För mer information om inspelningsleverantörer, konfigurationer och tilläggspartnertjänster, se Hantera samtalsinspelning för Webex Calling.
Tredjepartsintegrationer
stöder en mängdolika tredjepartsintegrationer inklusive men inte begränsat till SBC:er för lokala gateways, IP-telefoner, intercom-telefoner, Speaker/Pagers, ATA, etc. Utöver dessatredjepartsenheter har Webex Calling stöd för olikatredjepartslösningar för kundsupport, analys , inspelning, fakturering etc. För mer information om lösningar från tredje part , se Webex App Hub.
Planera
Projektplan på övergripande nivå
När man utvecklar en övergripande projektplan för migrering från till är det viktigt att fastställa tydliga faser och milstolpar som överensstämmer med både affärsmål och tekniska krav. Planen bör inledas med en omfattande bedömningsfas, inklusive insamling av detaljerade tekniska och affärsmässiga krav, samt identifiering av intressenter och definition av framgångskriterier. Viktiga överväganden inkluderar resursallokering, tidslinjeuppskattning, riskhantering och kommunikationsstrategier för att säkerställa att alla parter är informerade och engagerade under hela migreringen. Dessutom bör planen inkludera valideringskontroller som pilottester och etappvisa utrullningar för att minimera störningar och möjliggöra justeringar baserat på feedback.
Exempel på element att inkludera i projektplanen är:
-
Definiera migreringens omfattning (t.ex. vilka användare, enheter och funktioner som kommer att övergå)
-
Schemalägga utbildningstillfällen för slutanvändare och supportteam
-
Samordning av nätverksberedskapsbedömningar, och
-
Planering för övergångsaktiviteter med reservalternativ. Det är också viktigt att integrera efterlevnads- och säkerhetsgranskningar, samt support- och optimeringsfaser efter migrering.
Genom att strukturera projektplanen med dessa överväganden kan organisationer bättre hantera komplexitet, minska risker och uppnå en smidigare övergång till .
Migrationsresa – ett eller två steg?
kräver att användare använder för sina anropande mjukvaruklient. Därför, om några användare fortfarande använder , har du två alternativ för när du kan flytta dem till . Du kan antingen göra en användarmigrering i ett steg eller en användarmigrering i två steg.
Alternativ 1: Användarmigrering i ett steg
I en enda migrering övergår användare från till samtidigt som de övergår från Unified CM till . Det här alternativet är vanligtvis för kunder med ett litet antal användare att migrera och kan hantera att flytta både användarens mjukvaruklient och anropstjänst till samtidigt. Figuren Användarens samtalstjänst, mjukvaruklient & telefonen migrerar till samtidigt nedan markerar denna typ av migrering. Med det här alternativet kommer en användare att ha följande slutfört samtidigt:
-
Samtalstjänster flyttade från till
-
Telefonnummer och anknytningar flyttade från till
-
Mjukklienten övergick från Jabber till - kommer att registreras till
-
Telefonregistrering flyttad från till .
Detta kan fortfarande vara en etappvis migrering där grupper av användare flyttas vid olika tidpunkter, men när varje användare flyttas sker allt detta samtidigt.
Alternativ 2: Användarmigrering i två steg
Det andra tillvägagångssättet är en migrering i två steg. I steg 1 övergår användarna från till men stannar kvar för samtalstjänster. I steg 2 flyttas sedan användare från Unified CM till . Det här alternativet rekommenderas för större kunder som vill hantera slutanvändarändringar och vill separera användarens mjukklientändring från den anropande tjänständringen. Följande figur Migrera mjukvaruklient; migrera sedan anropstjänst, mjukvaruklient & telefon till Webex Calling nedan markerar denna typ av migrering.
Steg 1
-
Mjukklient övergången från till - kommer att registreras till .
Steg 2
-
Samtalstjänster flyttade från till .
-
Telefonnummer och anknytningar flyttade från till .
-
registreringen flyttad från till .
-
Telefonregistrering flyttad från till .
Detta kan fortfarande vara en etappvis migrering där grupper av användare flyttas vid olika tidpunkter i båda stegen.
Vilket alternativ du väljer beror på hur du vill hantera dina användares övergång till och . Rekommendationen är att ta det i steg (alternativ 2). Detta gör att du kan minimera slutanvändarens ändringar samtidigt och dela upp arbetet över olika delar av projektet. Om du däremot föredrar att användarna bara påverkas en gång, är alternativ 1 också giltigt.
Om man tittar på den rekommenderade resan (alternativ 1), visar övergångskartan för övergång från Jabber till Webex-appen figuren nedan övergången på övergripande nivå för steg 1.
I det här steget övergår användarna från Jabber till för alla sina samtalstjänster. Samtalsplattformen är dock fortfarande Unified CM och kommer att registrera sina samtalstjänster till . Som framgår av figuren översikten över övergången från Jabber till Webex-appen ändras inte den lokala infrastrukturen, och den fungerar på samma sätt som Jabber. Den enda förändringen är att det krävs en anslutning ut till .
För mer information om den här övergången, se Övergångskarta och distributionsguide för Jabber till Webex under avsnittet Klient på sidan Samarbetsövergång.
Övergångskarta för Unified CM till Webex Calling på hög nivå Figuren är övergången på hög nivå från till . Detta är steg 2 av den rekommenderade resan.
Om du väljer att använda enstegsmetoden gäller även detta.
I det här steget delas användarna in i grupper. Vid denna tidpunkt börjar användarna använda för sina samtalstjänster, samtalsregistrering och IP-telefonregistrering.
Eftersom användarna flyttas i grupper kommer företagsanvändare att delas mellan de två samtalsplattformarna under övergången. Fas 1 i Övergångskarta för Unified CM till Webex Calling på hög nivå visar detta tillstånd. Under denna fas krävs planering för hur samtal mellan användare på de två plattformarna ska hanteras och hur PSTN-samtal ska dirigeras. Varje gång en grupp användare övergår till krävs uppdateringar av uppringningsplaner och samtalsrouting på och den/de lokala gatewayen/gatewayerna.
När alla användare, mjukvaruklienter och enheter har övergått till (fas 2) kan all lokal UC-infrastruktur tas bort och avvecklas.
Designa
Regionval
är tillgänglig globalt och levereras från redundanta datacenter i flera regioner: USA (Dallas, Chicago), Kanada (Vancouver, Toronto), Europa (Frankfurt, Amsterdam), Storbritannien (London, Manchester), Australien (Melbourne, Sydney), Japan (Tokyo, Osaka), Saudiarabien (Riyadh, Jeddah) och Indien (Mumbai, Chennai). Medie-PoP:erna tillhandahåller medietjänster för att optimera medias tur-retur-tider. Datacentret i Singapore används till exempel för att optimera returtransporttiderna för media för kunder i asiatiska länder där returtransporttiderna till antingen Australien eller Japan kan vara suboptimala. Datacentren är sammankopplade med ett multigigabit- och helt redundant stamnät. Figuren globalt distribuerade datacenter visar en översikt över alla datacenter. För den senaste listan över tillgängliga datacenter, se Datacenterplatser för Webex Calling.
Varje kund är etablerad på en av instanserna. All provisioneringsinformation för den kunden lagras i den instansen och SIP-signaleringen för alla slutpunkter och lokala gateways som provisionerats för den kunden är kopplad till den instans som kunden är provisionerad på. Eftersom det är svårt att ändra det ursprungliga regionvalet är det viktigt att beakta alla relevanta faktorer som en del av beslutsprocessen som leder till regionvalet. För att undvika alltför långa fördröjningar i signaleringen är det viktigt att tidigt i övergångsprocessen bestämma vilken instans som ska användas. Cisco rekommenderar att man väljer den instans som ger de lägsta signaleringstiderna för det största antalet användare inom distributionen.
För tillgänglighet i olika länder, se Var är Webex tillgängligt?.
Platser
För att förbereda tillhandahållandet av platser behöver den information som krävs för alla migreringsmålplatser samlas in. Den information som behövs för varje plats sammanfattas i Information att samla in för varje plats.
| Information | Kommentar |
|---|---|
| Utökningsområde(n) | Varje plats kan ha tillägg som börjar med olika siffror. En siffra måste avvaras för styrsiffran för uppringning mellan platser (till exempel 8) och en för styrsiffran för PSTN (till exempel 9). Inget tilläggsområde kan börja med någon av dessa två siffror. Alla anknytningsintervall för alla platser måste vara lika långa. |
| DID-intervall | - |
| PSTN-styrningssiffra | - |
| Webbplatskod | Alla webbplatskoder för alla platser måste vara unika och ha samma längd. |
| Huvudnummer | När en plats skapas måste två DID:er etableras. Ett som huvudnummer (till exempel för att tilldelas en automatisk svarstjänst) och ett för röstbrevlådan. Tillhandahåll ett DID för röstbrevlådans nummer. |
| Röstbrevlådans nummer | |
| Antal licenser | Nödvändiga licenser efter typ inklusive Standard, Professionell, Arbetsyta, Ruttlista, Utgående samtalsplan. |
| Samtidiga samtal under högtrafik | Summan av samtidiga samtal mellan enheter och mellan enheter och den lokala gatewayen (PSTN och samtal till enheter). Behövs för att fastställa den erforderliga bandbredden för internetåtkomst. |
| Land | - |
| Tidszon | - |
| Språk | - |
| Kontakt (namn, telefon, e-postadress) | - |
| Adress (gatuadress, ort, delstat, postnummer) | - |
| Fysisk dispatchplats för räddningstjänstens slutpunkter | Enhetsavsändningsplats som används för nödsamtal inkluderar vanligtvis följande: byggnadsadress, byggnadsadress + våningsnummer, byggnadsadress + lägenhetsnummer eller byggnadsadress + våningsnummer + office/cubical antal. |
| Unik fysisk nätverksplats per enhet för räddningstjänster | Fysisk nätverksplats för nödsamtal inkluderar vanligtvis följande: växla / switchport för trådbundna enheter, trådlös åtkomstpunkt (AP) Basic Service Set Identifiers (BSSID) för trådlöst anslutna enheter, and/or Lokala IP-undernät för slutpunktsenheter. |
PSTN
När kunder utformar en driftsättning har de tre primära PSTN-anslutningsalternativ: Cisco Calling Plans (en molnlevererad PSTN-tjänst som hanteras av Cisco), Cloud Connected PSTN Providers (CCPP, där leverantörer levererar PSTN-tjänst via molnet) och lokala PSTN (där lokala gateways ansluter företagsnätverket till PSTN). Med introduktionen av PSTN-trunking för hybriddistributioner (för mer information, se PSTN-trunking för hybrid Webex Calling-distributioner på PSTN-trunking) får organisationer ytterligare flexibilitet i sin migreringsmetod. Den här funktionen gör det möjligt för kunder att flytta sitt PSTN till CCPP i början av övergångsprocessen och börja övergå till molnbaserad PSTN för användare, samtidigt som CCPP utnyttjas för att upprätthålla PSTN-tjänsten för användare som stannar kvar på Cisco under en stegvis migrering.
Denna hybridmetod gör det möjligt för organisationer att först flytta utvalda användargrupper till molnet, utan att omedelbart behöva omstrukturera hela sin telefonimiljö. Det introducerar dock ytterligare komplexitet och risker, särskilt kring att anpassa befintlig samtalsroutinglogik för att stödja den nya arkitekturen. Interoperabilitet med äldre applikationer, såsom faxservrar, kontaktcenter eller personsökarsystem, kräver också noggrant övervägande. Viktiga tekniska utmaningar kan innefatta att säkerställa sömlös end-to-end-codec-förhandling och DTMF-signalering (Dual-Tone Multi-Frequency) över den blandade miljön, samt att validera kompatibilitet med specialiserade telefonifunktioner. Korrekt planering och testning är avgörande för att minimera störningar och upprätthålla tillförlitliga rösttjänster under hela migreringsprocessen. Dessutom är kommersiella överväganden viktiga, eftersom hybrid trunking kräver en användningslicens som baseras på antalet samtidiga samtal mellan den lokala miljön och den molnanslutna PSTN-leverantören (CCPP).
Alternativt kan organisationer välja att behålla sin lokala PSTN-anslutning under hela övergångsfasen. I det här scenariot kan migrering till CCPP genomföras på två sätt: som en enda, samordnad övergång för alla användare och platser när migreringen är klar, eller stegvis, där PSTN-migrering sker per plats allt eftersom användare flyttas till . Denna metod kan bidra till att effektivisera samexistens och upprätthålla kontinuitet för äldre integrationer, men den medför flera operativa komplexiteter. Bland dessa finns utmaningar relaterade till nummerportering, såsom behovet av exakt samordning av nummerporteringsorder, potentiella förseningar och leverantörspålagda begränsningar, såsom ett tak för antalet samtidiga porteringsförfrågningar eller begränsningar för portering av delmängder av stora nummerblock. Organisationer måste noggrant planera sin PSTN-övergångsstrategi och ta hänsyn till dessa logistiska överväganden för att undvika avbrott i tjänsten och säkerställa en smidig migreringsupplevelse.
Figuren Migrering till CCCP vid start kontra att behålla lokalt PSTN visar de två PSTN-migreringsalternativ som förklarats ovan. Illustrationen till vänster visar scenariot där alla lokala användare och applikationer konsumerar molnanslutna PSTN-tjänster via en lokal trunk och en lokal gateway som ansluter den lokala nätanslutningen till nätanslutningen, medan illustrationen till höger visar scenariot där den befintliga lokala PSTN-tjänsten finns kvar och användare på Webex Calling använder lokal PSTN via den lokala gateway-anslutningen mellan nätanslutningen och nätanslutningen. Under övergången kan platser bytas till att använda molnansluten PSTN.
I båda fallen använder samtal mellan lokalt och användaren den lokala gateway-anslutningen. Anslutningen mellan den lokala och den lokala enheten måste utformas och dimensioneras därefter baserat på det förväntade antalet samtidiga samtal och den redundans som krävs.
Uppringnings plan
För att uppnå sömlös interoperabilitet mellan och under migreringsperioden måste en omfattande arkitektur för uppringningsplaner utvecklas och implementeras över båda plattformarna. Denna design med dubbla plattformar för uppringningsplan säkerställer konsekvent samtalsrouting, nummeröversättning och funktionstransparens, vilket gör det möjligt för användare på båda systemen att kommunicera utan försämrad tjänst eller störningar i användarupplevelsen under hela samexistensfasen.
Lokalt uppringningsplan in
Under övergången måste man ändra inställningarna för att möjliggöra samexistens mellan enheter som är registrerade på Unified CM och på företagets uppringningsplan så att åtminstone följande krav kan uppfyllas:
-
+E.164 ringer från till
-
Anknytning som ringer från till (inom anknytningsområdet men även mellan anknytningsområdet om anknytningsintervallet är unikt)
-
Förkortat nummer mellan platser från till
-
Tvingad uppringning inom nätet från till
-
Återuppringning från katalogen för missade samtal till destinationer på
-
PSTN-samtal från till PSTN om lokal PSTN används under övergången för
-
PSTN-anrop från till om PSTN-trunking för hybriddistributioner används under övergången för att ge PSTN-åtkomst till lokala användare via Cloud Connect för
-
Tvingad online från till
-
Anknytning ringer från till (mellan platser).
Om något av ovanstående inte stöds av uppringningsvanor före övergången, till exempel om ingen förkortad uppringningsvana mellan platser finns, behöver de inte nödvändigtvis introduceras under övergången.
Figuren Bästa praxis för uppringningsplan visar bästa praxis för uppringningsplanering enligt beskrivningen i Föredragen arkitektur för Cisco Collaboration 12.x Enterprise On-Premises Deployments, CVD. Viktiga egenskaper hos denna metod inkluderar:
-
Enskild partition för +E.164 katalognummer
-
Kärnrouting baserad på +E.164 ruttmönster
-
Normalisering av alla uppringningsvanor till +E.164 med hjälp av översättningsmönster
-
Användning av översättningsmönster som anropar sökutrymmesarv (alternativ Använd ursprungsmottagarens anropande sökutrymme inställt på översättningsmönster).
Till exempel PSTN-uppringning (9+1+10D) från en enhet i SJC som tillhandahållits med sökutrymme för linjeanrop kommer SJCInternational först att matchas av 9.1[2-9]XX[2-9]XXXXXX översättningsmönster som normaliserar den uppringda partens nummer till +E.164. Den sekundära sökningen använder sedan samma anropande sökutrymme SJCInternational igen (anropande sökutrymmesarv) och +E.164-digit strängen kommer antingen att matchas av en +E.164 katalognummer i DN -partitionen eller via ett av PSTN-ruttmönstren i USPSTNNational - eller SJCPSTNLocal -partitionen. Förkortade uppringningsvanor inom och mellan platser implementeras av översättningarna i partitionerna ESN och SJCtoE164. Medan ESN -partitionen är en global partition (tillgänglig för telefoner på alla platser) är SJCTOE164 -partitionen endast tillgänglig för användare på plats SJC. Detta förutsätter överlappande utvidgningsområden.
Det första steget för att aktivera anrop från till är att se till att +E.164 destinationer dirigeras därefter. Detta kan uppnås genom att lägga till en partition i uppringningsplanen, lägga till +E.164 ruttmönster för alla destinationer till den partitionen, och slutligen lägga till partitionen till alla anropande sökutrymmen som representerar tjänsteklasser som behöver kunna nå . Att skapa en dedikerad partition krävs för att möjliggöra skapandet av en differentierad tjänsteklass för samtal som kommer från . För att undvika samtalsloopar bör sökutrymmet för inkommande samtal på trunk-linjen från den lokala gatewayen inte ha åtkomst till partitionen.
Som visas i figur +E.164 dirigera till Webex Calling, för att aktivera dirigering från till för en plats med +E.164 DID-intervall +1 221 555 2XXX och platskod 121, ett brådskande ruttmönster som matchar detta +E.164 intervallet måste läggas till i -partitionen.
Om inget platsspecifikt val av lokal gateway krävs, kan ruttmönster som pekar till en enda ruttgrupp istället för att använda en ruttlista med en lokal ruttgrupp som destination, tillhandahållas med den lokala gatewayen som enda medlem och sedan pekar ruttmönstren till en enda ruttlista med denna enda ruttgrupp som enda post.
För att möjliggöra kortnummeruppringning mellan platser läggs det obligatoriska ruttmönstret 8121.2XXX till partitionen. För att webbplatser ska övergå till ett uppringningsnormaliseringsmönster 8121.2XXX som normaliserar ESN-uppringning till +E.164 kanske redan finns i ESN partitionen. I så fall verkar 8121.2XXX vara redundant, men så snart alla DN:n för respektive plats har migrerats till 8121.2XXX kan översättningsmönstret för uppringningsnormalisering tas bort och sedan möjliggör ruttmönstret 8121.2XXX ESN-uppringning även för användare som endast använder anknytningar inom det intervallet.
Med dessa ändringar i uppringningsplanen kan samtal till platsen göras inte bara genom att ringa förkortade mellanstationsnummer och +E.164. Även internationell och nationell PSTN-uppringning är möjlig eftersom dessa uppringningsvanor först normaliseras till +E.164 genom de redan befintliga översättningsmönstren för uppringningsnormalisering och sedan dirigeras till genom att matcha +E.164 ruttmönster i partitionen.
De +E.164 Matchning av ruttmönster på platsens DID-intervall kan tillhandahållas medan alla DID:er fortfarande finns på . Den bästa algoritmen för matchningsmönster ser till att när ett nummer som finns på rings upp så +E.164 katalognumret som provisionerats på är en bättre matchning än jokerteckenet +E.164 ruttmönster som pekar till så att samtalen vidarebefordras till en linje på och inte skickas till .
nummerplan
Varje användare har ett tillägg and/or en +E.164 telefonnummer. Förlängningslängden är en fast global inställning: alla tillägg i en distribution har samma längd. Uppringning via anknytning kan användas mellan användare både inom en plats och mellan platser. Förkortad uppringning mellan anknytningar (det senare fallet) fungerar bara om den uppringda anknytningen är unik.
Om förkortad uppringning mellan platser är ett krav men det finns överlappningar mellan anknytningar som är tilldelade på olika platser, måste en företagsspecifik nummerplan skapas genom att prefixa anknytningarna med en åtkomstkod (en platskod). För mer information, se Föredragen arkitektur för Cisco Collaboration 15 lokala implementeringar, designöversikt tillgänglig på Cisco Collaboration-föredragna arkitekturer.
Anknytningslängden, uppringningsbeteendet för interlokationsanknytning, prefixlängden för interlokationsuppringning och styrsiffran i routingprefixet för interlokationsuppringning konfigureras i inställningarna för samtalstjänsten i :
-
Längd på prefixet för platsrutning: Prefixlängd inklusive styrsiffran. Krävs endast om en företagsnummerplan behöver upprättas som alternativ förkortad företagsuppringning mellan platser.
-
Styrsiffra i routingprefix: Styrsiffra för förkortad uppringningsmetod för företag mellan platser. Överlappningar med den första siffran för valfri plats och platsens utgående siffror bör undvikas. Krävs endast om en företagsnummerplan behöver upprättas som alternativ förkortad företagsuppringning mellan platser.
-
Intern förlängningslängd: Standardlängd på förlängningar. Kan vara vilket värde som helst mellan två och tio.
När uppringning av anknytning eller uppringning med hjälp av företagssignifikanta nummer (styrkod, platskod, anknytning) krävs från en lokal samtalskontroll till och den lokala samtalskontrollen skickar en anknytning som uppringar-ID, se till att även ställa in parametern Maximal okänd anknytningslängd i avsnittet Samtalsroutning mellan och lokala för att säkerställa att uppströmssamtal från den lokala samtalskontrollen till kan klassificeras korrekt som lokala samtal. -
Tillåt uppringning av anknytning mellan platser: Växla till enable/disable anknytning som ringer mellan platser. Det här alternativet bör endast aktiveras om alla tillägg inom organisationen är unika. Om alternativet är inaktiverat måste företagsnummer (styrkod, platskod, anknytning) eller telefonnummer ringas mellan platser.
De tre första parametrarna används huvudsakligen för att skapa en uppringningsplan för telefoner för att minimera timeout mellan siffror vid uppringning med luren av. Avvikelser från dessa globala inställningar är fortfarande möjliga (exempel – anknytningar med annan längd kan etableras), men ett varningsmeddelande visas i Control Hub och uppringning från telefoner kan kräva blockering för att undvika konflikter inom den förinstallerade uppringningsplanen.
Tabellen Exempel på företagsnumrering visar ett exempel på tre platser där anknytningsintervallen för två platser, NYC och RTP, är identiska. Att etablera ett företagsnummerschema med styrsiffran 8mellan platser, följt av en tresiffrig platskod och den fyrsiffriga anknytningen skapar en icke-överlappande förkortad uppringningsruta mellan platser.
| Webbplats | Förlängningsområde | Webbplatskod | Företagssortiment |
|---|---|---|---|
| New York | 2XXX | 202 | 8 202 2XXX |
| SFO | 3XXX | 203 | 8 203 3XXX |
| RTP | 2XXX | 204 | 8 204 2XXX |
För att möjliggöra en smidig övergång bör uppringningsvanorna för användare före och efter övergången till idealiskt sett vara desamma. För att förbereda övergången för varje plats måste DID-intervallen och anknytningsintervallen (eller förkortade uppringningsvanor inom platsen) dokumenteras. Baserat på denna information måste sedan styrsiffran mellan platserna väljas.
Tabellen Förlängningsområden med fast längd visar ett exempel på tre platser och förlängningsområden med fast längd. Eftersom överlappande uppringningsvanor måste undvikas är det viktigt att se till att den första siffran i intervallet för alla anknytningsintervall inte matchar styrsiffran för förkortad uppringning mellan platser. Om till exempel 8 väljs som styrsiffra för uppringning mellan platser, kan inget anknytningsområde på någon plats börja med 8. Vanligtvis matchar anknytningarna på en given plats de sista siffrorna i de DID:er som tilldelats den platsen. För att undvika konflikter kan den första siffran i anknytningen ändras. Om till exempel DID:er i +1 408 555 8XXX-intervallet används på en plats, kan istället för att använda 8XXX som anknytningsområde 7XXX användas för anknytningarna på den platsen.
| Webbplats | Förlängningsområde | Anknytningar | Webbplatskod | Företagssortiment |
|---|---|---|---|---|
| New York | 2XXX | 2XXX | 202 | 8 202 2XXX |
| SFO | 8XXX | 7XXX | 203 | 8 203 7XXX |
| RTP | 1XX | 11XX | 204 | 8 204 11XX |
Sjusiffriga uppringningssträngar som ringts upp på en enhet med den amerikanska uppringningsplanen överlappar ett sjusiffrigt mönster för lokal uppringning i den förinstallerade amerikanska uppringningsplanen. För att undvika överlappningar mellan uppringningsvanor online och utanför nätet (PSTN) kan en obligatorisk extern accesskod användas på den platsen. Om det befintliga företagsnumreringsschemat och motsvarande förkortade uppringning mellan platser överlappar med mönster i det nationella numret, kan numreringsschemat under övergången till numreringsschemat också ändras till en längre eller kortare form för att undvika överlappningar. Det enklaste sättet att uppnå detta är att lägga till en extra utfyllnadssiffra i numreringsschemat. Det nya schemat för längre uppringning mellan webbplatser behöver bara implementeras av användare som redan har migrerat till . Användare som fortfarande är på kan fortsätta att ringa sju siffror. Företagsuppringningsplanen måste i det här fallet se till att förkortade sjusiffriga uppringningar från Unified CM omvandlas till antingen +E.164 eller till det förkortade uppringningsformat som används på . Detta måste göras innan samtalet skickas till den lokala gatewayen.
Tabellen Övergång till sjusiffrig uppringning visar ett exempel på denna omnumrering. I det här exemplet använder förkortad uppringning mellan platser styrsiffran 8 följt av en tvåsiffrig platskod och en fyrsiffrig anknytning. För att undvika sjusiffriga förkortade uppringningar mellan platser på , kan platskoderna enkelt ändras till tresiffriga genom att lägga till en godtycklig utfyllnadssiffra (8 i exemplet) före de tvåsiffriga platskoderna som används i så att uppringning mellan platser från telefoner använder styrsiffran 8 följt av utfyllnadssiffran 8, den gamla tvåsiffriga platskoden och den fyrsiffriga anknytningen. Användare på behöver inte komma ihåg nya platskoder; de behöver bara komma ihåg att använda 88 som prefix för uppringning mellan platser istället för 8 på .
| Webbplats | Anknytningar | Webbplatskod | Företagssortiment | Webbplatsens ode | Företagsange |
| New York | 2XXX | 22 | 8 22 2XXX | 822 | 8 822 2XXX |
| SFO | 8XXX | 23 | 8 23 7XXX | 823 | 8 823 7XXX |
| RTP | 1XXX | 24 | 8 24 11XX | 824 | 8 824 11XX |
I ett scenario med olika företagsnummerformat aktiverade, och om företagsnummer presenteras som information om uppringande part för samtal från till (till exempel samtal från enheter utan DID), är det viktigt att också implementera en mappning mellan de olika nummerformaten för information om uppringande part för att säkerställa att återuppringning fungerar. Denna mappning kan uppnås genom att använda det anropande partens transformationsmönster på trunk mellan och den lokala gatewayen.
Inspelning
En väl utformad lösning för samtalsinspelning kräver noggrant övervägande av flera viktiga designelement för att säkerställa att den överensstämmer med organisationens mål, myndighetskrav och tekniska begränsningar. Två av de viktigaste besluten rör val av leverantör och val av region, vilka båda kan behöva anpassas globalt och åsidosättas på specifika platser, baserat på affärsbehov.
1. Val av leverantör för samtalsinspelning
Att välja rätt leverantör av samtalsinspelning är grundläggande för att uppnå affärsmål och säkerställa funktionsanpassning i hela organisationen:
-
Globalt leverantörsval: Organisationer utser vanligtvis en primär leverantör av samtalsinspelning på global nivå, vilket säkerställer enhetlighet i funktioner, efterlevnad och support på alla platser.
-
Platsbaserade åsidosättningar: I scenarier där specifika platser eller regioner har unika affärsbehov eller myndighetskrav kan det vara nödvändigt att åsidosätta det globala leverantörsvalet och ange alternativa leverantörer för dessa platser. Denna flexibilitet stöder varierande efterlevnadskrav och lokala operativa behov
-
Företagskrav: Valet av leverantör bör styras av en bedömning av affärsdrivande faktorer såsom regelefterlevnad (exempel - MiFID II, HIPAA), kvalitetssäkring, tvistlösning eller utbildningsbehov.
-
Funktionstillgänglighet: Leverantörer bör utvärderas baserat på deras förmåga att leverera nödvändiga funktioner, såsom realtidsövervakning, sök- och uppspelningsfunktioner, kryptering, lagringspolicyer, integration med analysplattformar och stöd för olika samtalstyper (inkommande, utgående, interna).
2. Regionval
Att fastställa regionen där samtalsinspelningar lagras och bearbetas är avgörande för efterlevnad och prestanda:
-
Val av global region: Som standard kan organisationer välja en enda region för att lagra samtalsinspelningar för att förenkla hantering och styrning.
-
Platsbaserade regionåsidosättningar: Där lagar om datalagring eller företagspolicyer kräver det kan det vara nödvändigt att åsidosätta den globala regioninställningen för specifika platser, vilket säkerställer att samtalsinspelningar lagras och bearbetas inom de geografiska gränserna som krävs.
-
Krav på datalagring: Designen måste ta hänsyn till internationella och lokala dataskyddsföreskrifter (såsom GDPR, CCPA eller landsspecifika krav) som kan avgöra var och hur samtalsinspelningar lagras.
En annan viktig aspekt att beakta under planeringen och designen av en lösning för samtalsinspelning är uppskattningen av lagringsbehov. Att noggrant prognostisera lagringsbehov är avgörande för att säkerställa att tillräcklig kapacitet finns tillgänglig för att stödja den löpande affärsverksamheten, upprätthålla efterlevnad och undvika avbrott i tjänsten.
Flera viktiga parametrar bör beaktas vid bestämning av det förväntade lagringsbehovet:
-
Antal inspelade samtal: Bedöm det förväntade antalet samtal som kommer att spelas in inom ett givet tidsintervall (t.ex. per dag, vecka eller månad). Detta inkluderar inte bara externa samtal utan även intern kommunikation, om det krävs enligt affärspolicy eller myndighetsmandat.
-
Genomsnittlig samtalslängd: Beräkna den typiska längden på inspelade samtal, eftersom längre samtal tar upp mer lagringsutrymme. Variationer i samtalslängd mellan olika avdelningar eller användargrupper bör också beaktas i uppskattningen.
-
Lagringsperiod: Definiera hur länge inspelningar måste lagras, vilket ofta dikteras av organisationens policyer eller externa regler (t.ex. branschspecifika efterlevnadsstandarder). Längre lagringsperioder kommer att öka de totala lagringsbehoven
-
Tillväxtprognoser: Överväg förväntad tillväxt i samtalsvolymer eller utökning av inspelningsomfattningen, vilket kan bero på skalning av verksamheten, nya myndighetskrav eller onboarding av ytterligare användare eller platser.
Genom att noggrant analysera dessa parametrar kan organisationer utveckla en robust lagringsstrategi som säkerställer skalbarhet, kostnadseffektivitet och regelefterlevnad för sin samtalsinspelningslösning. Det är också lämpligt att regelbundet granska och justera lagringsallokeringar allt eftersom användningsmönstren utvecklas över tid.
Nödsamtal
Kravet att dirigera ett nödsamtal till lämplig larmcentral är ett krav för alla samtalstjänster som erbjuder PSTN-tjänster. Med är dirigering av nödsamtal inbyggd i lösningen och inkluderar stöd för alla nationella nödnummer i de länder som stöder . Dirigeringen av ett nödsamtal baseras på den definierade platsen inom och platsens PSTN-åtkomstmetod. Nödnumren är fördefinierade och specifika för det land där användarna och enheterna finns.
Det finns två metoder för att ringa nödsamtal. Det finns en grundläggande nödsamtalsomdirigeringstjänst och en utökad nödsamtalsomdirigeringstjänst. Den grundläggande dirigeringstjänsten för nödsamtal använder ett administratörsvalt nummer för att identifiera platsen och ringa räddningstjänsten. För grundläggande nödsamtal går samtalsvägen vanligtvis via kundens PSTN-alternativ för den platsen. har även förbättrad dirigering av nödsamtal utformad för implementeringar i USA och Kanada som har regelefterlevnadskrav som kräver användning av en rikstäckande leverantör för att leverera nödsamtal till rätt larmcentral.
Alla kunder bör implementera, som minimum, den grundläggande konfigurationen för nödsamtal. Grundläggande nödsamtal kräver att minst en kund ägs +E.164 nummer tilldelas varje plats som definieras i . För grundläggande nödsamtal definieras varje plats av en gatuadress dit polis, brandkår eller ambulans skickas i nödfall. I de flesta fall är huvudnumret för platsen det bästa valet för att representera den fysiska platsen för nödsituationen. Vanligtvis är tilldelningen av adressen till +E.164 Numret koordineras med PSTN-leverantören. Bilderna nedan visar tilldelningen av huvudnumret som ska användas som nödnummer för Richardson-platsen.
I de flesta fall räcker det med en byggnadsadress som avsändningsadress för platsen. Men om ytterligare platsinformation behövs för specifika användare eller enheter kan en administratör använda samma process som beskrivs ovan och tilldela dessa enheter till en specifik adress eller en mer exakt plats inuti adressen (t.ex. en våning eller ett rum). I Användarhantering i , tillåter fliken Samtal att ett specifikt nummer används för en användare och deras enheter för att få en specifik leveransadress. Följande bilder illustrerar hur ett specifikt nummer kan tilldelas en enhet. Administratören ansvarar för att se till att numret som används av enheten har rätt avsändaradress tilldelad. Adresstilldelningen görs vanligtvis via PSTN-leverantören för den platsen.
För USA-baserade telefoniinstallationer som måste tillhandahålla förbättrade nödsamtallösningar används RedSkys Horizon Mobility integrerad för dirigering av nödsamtal. När man använder RedSky för samtalsdirigering måste en administratör registrera ett konto via Cisco och konfigurera lämplig information i Ringer -> Tjänstinställningar för att aktivera den här funktionen. När RedSky-tjänsten har aktiverats på systemnivå kommer en administratör att aktivera RedSky-tjänsten på varje platsnivå. Aktivering av Utökade Nödsamtal på en plats aktiverar tjänsten för alla enheter som är tilldelade den platsen. Enheter som stöder utökade nödsamtal är Cisco MPP-telefoner, Cisco PhoneOS-telefoner och Ciscos .
Det finns två inställningar för att aktivera utökade nödsamtal på en plats. Funktionen Tillåt RedSky att ta emot information om nätverksanslutning och testanrop bör användas för att verifiera att RedSky-konfigurationen för enhets- och infrastrukturmappningar är korrekta. Den här inställningen gör det också möjligt att ringa testsamtal till 933 för att utföra platsverifiering med hjälp av RedSkys IVR-system för att läsa av uppringarens plats. Även om det här dokumentet inte täcker RedSky-konfigurationen för platsspårning, bör en administratör ALLTID testa sin platsidentifiering innan nödsamtal kopplas till RedSky. När testningen har slutförts och verifierats som korrekt, kommer administratören att dirigera samtal till RedSky genom att växla dirigeringen av nödsamtal till RedSky. Den här växlingsknappen dirigerar alla nödsamtal för platsen till RedSky för leverans till platsens svarscentral.
Inställningarna för utökade nödsamtal gäller även för klienter både lokala och externa. När de är lokala kan de spåras på samma sätt som bordstelefoner spåras. När användaren befinner sig utanför lokalen kommer hen att kunna ange sin plats dynamiskt direkt i . För mer information om nödsamtal, se Utökade nödsamtal för .
Licensiering
Det finns flera alternativ för att tilldela licenser till användare.
Manuell tilldelning via
Administratörer tilldelar manuellt licenser till enskilda användare via gränssnittet.
Administratörer kan redigera servicelicenser för enskilda användare och tilldela samtalslicenser direkt.
Mallar för automatisk licenstilldelning
Använd licenstilldelningsmallar för att automatiskt tilldela licenser till användare baserat på grupp- eller organisationsinställningar.
Automatisk licensiering kan göras via katalogsynkronisering eller manuella användaruppdateringar, men användare måste ha ett giltigt +E.164 formaterat telefonnummer och telefonnumren måste finnas på en plats innan användarprovisionering. Om villkoren inte är uppfyllda (t.ex. ogiltigt telefonnummerformat) kommer licenser inte att tilldelas.
Masstilldelning via CSV-mall
Ladda upp en CSV-fil med användaruppgifter och licenstilldelningar för att lägga till eller ändra flera användare samtidigt.
CSV-import stöder tillägg av upp till 20 000 användare och tilldelning av licenser, men licenser kräver specifika fält som telefonnummer och anknytning.
API-baserad tilldelning
Använd API:er för att programmatiskt tilldela licenser och hantera användare.
stöder API-operationer för användar- och licenshantering (People, SCIM 2.0 och Licenses API:er), vilket kan utnyttjas för automatisering av licenstilldelning. Licenses API möjliggör samtidig tilldelning av licenser, telefonnummer och anknytningar.
| Tilldelningsmetod | Fördelar | Nackdelar |
|---|---|---|
| Manuellt genom | Enkelt för ett fåtal användare. Ger exakt och detaljerad kontroll över licenstilldelning. | Inte skalbar, tidskrävande Benägenhet för mänskliga fel vid manuell inmatning. |
| Automatiska licensmallar | Skalbar Minskar manuella fel Kan tillämpas på nya och befintliga användare. | Kräver giltiga telefonnummer och platser. Mer komplex att ställa in Kräver även användargrupper per användargrupp med motsvarande licenskrav. |
| Massuppladdning av CSV | Effektiv för stora användargrupper Tillåter samtidig tilldelning av licenser, telefonnummer och anknytningar. | Kräver noggrann CSV-formatering Risk för fel om telefonnummer eller anknytningar saknas eller är felaktiga. |
| API-baserad tilldelning | Automatiserad, flexibel. Tillåter samtidig tilldelning av licenser, telefonnummer och anknytningar. | Kräver utvecklings- och API-kunskap. |
Tabellen Användarprovisioneringsalternativ - sammanfattning sammanfattar användarprovisioneringsalternativ och deras för- och nackdelar. Den här översikten hjälper dig att välja den bästa metoden för licenstilldelning baserat på kundens organisationsstorlek, automatiseringsmöjligheter samt processer och krav för användarprovisionering.
Där det är möjligt rekommenderar Cisco att man tilldelar samtalslicenser med hjälp av licensmallar. Detta kräver att det för varje användargrupp som kräver en unik uppsättning licenser (exempel - Standard vs. Professional) finns en grupp med respektive gruppmedlemskap. Som diskuterats i avsnitten Användargrupper kan användargrupper definieras manuellt i eller synkroniseras från en företagskatalog. En kombination av båda tillvägagångssätten är möjlig.
Användare som tillhör flera grupper får licenser från alla tilldelningar som tillämpas på alla deras grupper. Detta gör det möjligt att använda licensspecifika säkerhetsgrupper i företagskatalogen för att hantera licenstilldelning där den resulterande användarlicenstilldelningen styrs av sammanslagningen av gruppmedlemskap.
För mer information, se Konfigurera automatiska licenstilldelningar i Control Hub och Konfigurera mallar för automatiska licenstilldelningar för Webex Calling-användare.
Licenskrav
Detta avsnitt behandlar endast relaterade licenser. Andra licenstyper (exempel – Webex-enhetsregistrering, meddelanden, möten) omfattas inte. Som en del av designprocessen måste licenskraven fastställas. Antalet licenser för följande licenstyper behöver beräknas:
-
Standard: antal enskilda användare som behöver standardfunktioner för telefoni.
-
Professionell: antal användare och arbetsytor som kräver avancerade telefonifunktioner. Virtuella linjer och gruppröstbrevlåda har rätt till en 1:1 förhållande för varje yrkeslicens. I sällsynta fall där antalet nödvändiga virtuella linjer eller gruppröstmeddelanden överstiger antalet användare och arbetsytor som kräver avancerade telefonifunktioner, måste därför ytterligare professionella licenser beaktas.
-
Arbetsyta för gemensamt område: antal platser för delat bruk eller gemensamma utrymmen som kräver standardsamtal.
-
Kundsupport: antal agenter och handledare som behöver Customer Assist-funktioner. Kundsupporten inkluderar Professional-licensen.
-
Ruttlista-anrop: antal obligatoriska molnanslutna PSTN-samtal mellan lokala användare and/or lokala specialiserade tredjepartsapplikationer.
-
Operatörskonsol: antal användare som behöver åtkomst till attendant-konsolklienten.
-
Cisco-samtalsplan (utgående samtalsplan): antal användare som behöver ett PSTN-nummer and/or åtkomst till utgående PSTN-samtal för Cisco PSTN-tjänsten.
Det finns ingen dedikerad licenstyp för professionella arbetsytor. Professionella arbetsytor använder en professionell licens.
Arbetsplatser som endast erbjuder hot desking-värdtjänsten och nödsamtal från hot desking-värden och kräver ingen licens. För mer information, se Lägga till och hantera endast hot desk-enheter.
För att fastställa vilken licenstyp som krävs för varje användare och arbetsyta baserat på de funktioner som behövs, se Funktioner tillgängliga efter licenstyp för Webex Calling.
För att skilja mellan funktioner som erbjuds av samtalsköer i kombination med den professionella licensen i motsats till kundassistans, se Jämförelse av Webex Calling-funktioner för samtalsköer och kundassistans.
Användaretablering
När man etablerar användare i Webex finns det flera alternativ tillgängliga, som alla passar olika organisationsbehov och miljöer:
-
Manuell provisionering: Administratörer kan lägga till och hantera enskilda användare direkt i . Den här metoden är enkel men passar bäst för små organisationer eller begränsade användarändringar.
-
Massprovisionering via CSV: För större användarbaser kan administratörer importera och uppdatera användare samtidigt genom att ladda upp CSV-filer till . Detta möjliggör effektiv hantering av upp till tusentals användare samtidigt.
- Alternativ för katalogsynkronisering:
Katalogkoppling: Detta är ett automatiskt synkroniseringsverktyg som används i Microsoft Active Directory-miljöer. Den synkroniserar användarkonton, grupper och attribut enligt schema (timmevis, dagligen eller veckovis). Den stöder Active Directory-konfigurationer för flera domäner och flera skogar och kan synkronisera profilbilder och rumsobjekt.
Guideapp för Entra ID (Azure AD): Den här metoden är utformad för organisationer som använder Microsoft Entra ID (Azure AD) och ger automatisk synkronisering av användarkonton och attribut i nära realtid direkt från Entra ID till . Den hanteras helt internt och kräver minimal installation.
SCIM 2.0-applikationer: För miljöer som inte är från Microsoft eller andra identitetsleverantörer som Okta eller Duo, möjliggör SCIM-baserade synkroniseringsappar automatisk användarprovisionering och avprovisionering med attributmappning och gruppsynkronisering.
-
Synkronisering av enhetlig CM-användare: Det här alternativet gör det möjligt att skapa användarkonton baserat på befintliga slutanvändare genom att synkronisera från till . Detta kräver att Cloud Connected UC (CCUC) körs på de lokala klustren. Det rekommenderas dock generellt att synkronisera användare från en centraliserad molnkatalog som Entra ID snarare än direkt från .
-
API-provisionering: Offentliga API:er (People, SCIM 2.0) kan användas för att etablera användare. Den största fördelen med att använda API:er är möjligheten att integrera användarprovisioneringen med andra företagssystem.
Denna översikt och tabell återspeglar de viktigaste alternativen för användarprovisionering, deras fördelar och begränsningar för att hjälpa dig välja den bästa metoden för din organisations behov.Tabell 6. Alternativ för användaradministration för Provisioneringsmetod Beskrivning Fördelar Nackdelar Manuellt Create/manage användare individuellt i Enkelt för få användare; ingen infrastruktur behövs Inte skalbar; tidskrävande för många användare Massvis (CSV-fil) Import/update användare i bulk via CSV i Effektivt för grupper; ingen kodning krävs Manuell CSV-förberedelse; mindre dynamisk Människor och SCIM 2.0 API Programmatisk användarhantering via Webex API:er Flexibel; stöder automatisering och integration Kräver utveckling och infrastruktur Katalogsynkronisering Automatisk synkronisering från AD, Entra ID, SCIM-appar, Unified CM Automatiserar livscykeln; stöder filtrering och mappning Komplexitet i installationen: vissa av alternativen har begränsade funktioner eller kräver infrastruktur
Användargrupper
Med hantering av användargrupper kan administratörer organisera användare i grupper för effektiv masshantering av licenser, inställningar och resurser. Grupper hjälper till att effektivisera administrationen genom att tillämpa policyer, licenser och inställningsmallar på flera användare samtidigt, istället för att hantera användare individuellt.
Hantering av användargrupper erbjuder flera fördelar, inklusive:
-
Förenklad administration: Hantera licenser, inställningar och policyer för flera användare samtidigt.
-
Konsekvens: Tillämpa enhetliga inställningar och licenser för alla användare i samma grupp.
-
Skalbarhet: Stöder upp till 250 000 medlemmar per grupp.
-
Integrering: Synkronisera grupper från Microsoft Entra ID (Azure AD) eller Active Directory för automatiserad användar- och grupphantering.
-
Flexibilitet: Skapa lokala grupper eller synkronisera säkerhetsgrupper; hantera gruppmedlemskap manuellt eller via CSV-filer.
-
Resursallokering: Styr åtkomst till inbäddade appar och tjänster baserat på gruppmedlemskap.
De huvudsakliga användningsområdena för användargrupper vid provisionering är:
-
Licenstilldelningar: Tilldela licenser till grupper för att automatiskt tillhandahålla tjänster som samtal, möten, meddelanden eller hybridtjänster till gruppmedlemmar.
-
Inställningsmallar: Tillämpa samlingar av tjänstinställningar (t.ex. meddelanden, möten, samtal) på grupper för en enhetlig användarupplevelse.
-
Massanvändarhantering: Lägg till eller ta bort användare samtidigt via CSV-filer eller katalogsynkronisering.
-
Automatisering och integration: Använd API:er eller katalogsynkronisering för automatiserad hantering av användare och gruppers livscykel.
Följande tabell sammanfattar de olika alternativen för att hantera användargrupper och grupphantering i .
| Alternativ | Beskrivning | Fördelar | Nackdelar |
|---|---|---|---|
| gruppprovisionering (grupper) | Skapa och hantera grupper direkt i . Add/remove medlemmar manuellt eller via CSV. | Full kontroll över gruppmedlemskap Omedelbar tillämpning av licenser och mallar Enkelt att skapa och redigera grupper |
Manuella uppdateringar krävs Risk för fel vid manuella CSV-uppladdningar Ingen automatisk synkronisering med externa kataloger |
| Synkroniserade grupper från Entra ID (Azure AD) eller Active Directory | Synkronisera automatiskt säkerhetsgrupper och medlemskap från externa katalogtjänster. | Automatiserad synkronisering minskar manuellt arbete Säkerställer överensstämmelse med företagskatalogen Stödjer stora organisationer |
Kan inte redigera gruppmedlemskap i Synkroniseringsfördröjning upp till 12 timmar Kapslade grupper kräver manuellt val |
| Grupper och SCIM 2.0 API (Grupper) | Använd Groups eller SCIM 2.0 API för programmatisk grupp- och medlemshantering | Automatisering och integration med andra system Skalbar för stora eller komplexa miljöer |
Kräver utvecklingsinsatser Komplexiteten beror på API-användning |
Medan synkroniserade grupper säkerställer konsekvens och erbjuder en enda administrationspunkt, är en hybridmetod som kombinerar synkroniserade grupper och grupper (antingen hanterade i kontrollhubben eller via API:er) möjlig. Så kan till exempel grupper för licenstilldelning vara synkroniserade grupper och en separat uppsättning grupper kan användas för att tilldela användar- och anropsmallar.
Denna omfattande metod för hantering av användargrupper gör det möjligt för organisationer att effektivt hantera användarlicenser, inställningar och policyer, vilket säkerställer konsekventa och skalbara samarbetsupplevelser.
Rekommenderad metod vid migrering från till
Den primära datakällan för användare är databasen, som innehåller information om slutanvändare. är dock vanligtvis inte den auktoritativa källan för hantering av användaridentiteter och, ännu viktigare, kommer att stängas ner i slutet av övergången och är därför utesluten som en långsiktig auktoritativ källa för identitetsinformation.
Cisco rekommenderar att man använder en centraliserad molnkatalog, till exempel Microsoft Entra ID (Azure AD), som enda sanningskälla för användaridentiteter. Synkronisering av användare från Entra ID säkerställer konsekvens, förenklar hantering och stöder funktioner för enkel inloggning (SSO).
För att säkerställa att alla användare också finns i Entra ID bör organisationer verifiera att användarkontona motsvarar kontona i Entra ID. Detta kan göras genom att exportera användarlistor från och jämföra dem med Entra ID-användarlistor.
Sammanfattningsvis är den rekommenderade etableringsmetoden att synkronisera användare från Microsoft Entra ID (Azure AD) till Webex med hjälp av Azure AD-guiden eller SCIM-appar. Manuell och CSV-bulkprovisionering finns tillgängliga som kompletterande metoder men är mindre skalbara och mer felbenägna för stora organisationer. Att säkerställa att Entra ID är den auktoritativa källan och att alla användare finns i Entra ID är avgörande för en lyckad migrering och en enhetlig användarupplevelse över alla miljöer.
Övergången från en lokal katalogtjänst, som Active Directory, till en molnkatalogtjänst, som Entra ID (Azure ID), är oberoende av den anropande övergången. Cisco rekommenderar att övergången till en molnkatalogtjänst slutförs innan anropsövergången påbörjas.
Utforma användargrupper
Efter att företagskatalogen har överförts från lokal till molnet, samla in de användargrupper som krävs baserat på licens- och funktionsmallar. För varje gruppdokument:
-
Gruppnamn: gruppens unika namn.
-
Licenser: licenser som ska tilldelas denna grupp (om några) och omfattning (ska licenser tilldelas befintliga användare eller endast nya användare)
-
Inställningsmallar: Webex-app och användarsamtalmallar.
-
Katalogsynkronisering: Kommer den här gruppen att synkroniseras från företagskatalogen eller är detta en lokal Webex-grupp som etablerats i Control Hub eller via ett API.
-
Beskrivning: hur kommer den här gruppen att användas och vilka användare som ska vara medlemmar i gruppen
Dessa uppgifter kommer att användas senare under implementeringsfasen för att skapa lokala grupper eller grupper i företagskatalogen och hantera gruppmedlemskap för användare.
Enkel inloggning (SSO)
Cisco rekommenderar användning av SSO för användarautentisering. Att använda SSO har några övertygande fördelar, inklusive:
-
Förenklad användarautentisering: Användare kan logga in en gång med sina företagsuppgifter (t.ex. från Azure ID) för att komma åt och andra integrerade applikationer, vilket eliminerar behovet av flera lösenord och minskar antalet inloggningsfrågor. Detta förbättrar säkerheten genom att säkerställa att företagslösenord aldrig lagras eller överförs efter autentisering.
-
Förenklad användarhantering: Automatiserar skapande, uppdateringar och inaktivering av användarkonton baserat på ändringar i företagskatalogen, vilket minskar administrativa kostnader och säkerställer att endast behöriga användare har åtkomst.
-
Förbättrad säkerhet: SSO minskar lösenordströtthet och risken för lösenordsrelaterade intrång genom att centralisera autentisering via betrodda identitetsleverantörer (IdP:er).
-
Enkel integration av multifaktorautentisering (MFA): MFA kan enkelt stödjas antingen genom en Identity Access Management-lösning som Cisco Duo eller genom MFA-stöd för IdP:n.
Det finns flera alternativ för att implementera SSO för tjänster:
-
SAML 2.0-baserad SSO: Det primära protokollet som stöds för SSO-integration, vilket möjliggör säkert utbyte av autentiseringsinformation mellan IdP:n och tjänsteleverantören.
-
OpenID-anslutning (OIDC): Stöds som ett alternativt modernt autentiseringsprotokoll för SSO-integration.
-
Webex-identitet: Stöds även som ett identitetsleverantörsalternativ.
SSO konfigureras och hanteras centralt via , vilket kräver metadatautbyte mellan och den valda IdP:n.
Efter konfigurationen kan SSO testas innan aktivering för att säkerställa korrekt installation.
Cisco stöder integration med flera testade och vanligt förekommande IdP:er och identitetshanteringssystem (IAM), inklusive men inte begränsat till:
-
Cisco Duo
-
Okta
-
Microsoft Active Directory Federation Services (ADFS)
-
Microsoft Azure
-
PingFederate
-
OpenAM
-
F5 STOR-IP.
Dessa IdP:er överensstämmer med SAML 2.0- eller OpenID Connect-standarder och har validerats för kompatibilitet med Ciscos samarbetslösningar.
Stöd för flera IdP
låter organisationer konfigurera SSO med flera IdP:er för att hantera komplexa IT-miljöer som fusioner, förvärv eller decentraliserade IT-avdelningar där olika grupper använder olika IdP:er. Stöd för flera IdP kan antingen implementeras med hjälp av funktionen för flera IdP i eller genom integration med ett företags-IAM-system som Cisco Duo.
s stöd för flera identitetsleverantörer (IdP) adresserar flera viktiga användningsfall där organisationer behöver flexibel och säker autentisering i olika IT-miljöer:
1. Sammanslagna och förvärv
När företag går samman eller förvärvar andra har de ofta separata IT-infrastrukturer och distinkta IdP:er som inte kan federera. Stöd för flera IdP gör det möjligt för användare från båda organisationerna att autentisera och samarbeta säkert utan att behöva förena sina identitetssystem omedelbart.
2. Flera oberoende IT-avdelningar
Stora organisationer eller myndigheter kan ha flera oberoende IT-avdelningar, som var och en hanterar sin egen IdP. s funktion för flera IdP gör det möjligt för dessa avdelningar att underhålla sina egna autentiseringssystem samtidigt som användarna får smidig åtkomst.
3. Olika användargrupper eller domäner
Organisationer med olika användargrupper (t.ex. anställda kontra entreprenörer) eller flera e-postdomäner kan konfigurera routningsregler för att dirigera autentiseringsförfrågningar till lämplig IdP baserat på domän- eller gruppmedlemskap. Detta stöder differentierade åtkomstpolicyer och säkerhetskontroller.
4. Stöd för olika autentiseringsprotokoll
stöder SAML- och OpenID Connect (OIDC) IdP:er, vilket gör det möjligt för organisationer att integrera olika typer av identitetsleverantörer enligt deras befintliga infrastruktur och säkerhetskrav.
5. Förbättrad säkerhet och efterlevnad
Genom att aktivera flera IdP:er kan organisationer implementera starkare autentiseringsmekanismer, inklusive flerfaktorsautentisering (MFA) genom integrationer som Duo, och tillämpa konsekventa säkerhetspolicyer över olika användarbaser.
6. Förenklad användarupplevelse
Användare kan autentisera med sina befintliga inloggningsuppgifter från sina respektive IdP:er, vilket ger en enhetlig inloggningsupplevelse trots den underliggande komplexiteten hos flera identitetssystem.
Även om stöd för flera IdP ger flexibilitet, kräver det noggrann samordning mellan säkerhets- och identitetsteam för att upprätthålla konsekventa säkerhetspolicyer och undvika potentiella sårbarheter.
Duo MFA med SSO för
Duo Access Gateway (DAG) kan autentisera användare med hjälp av befintliga lokala eller molnbaserade kataloger som Active Directory (AD) och OpenLDAP. Den stöder även integration med andra identitetsleverantörer som Microsoft ADFS, Microsoft Azure, Okta, OneLogin, CAS och Shibboleth. Denna flexibilitet gör det möjligt för organisationer att använda sin nuvarande kataloginfrastruktur för Webex SSO med Duo MFA.
Duo fungerar som ett starkt autentiseringslager utöver autentiseringen av den primära katalogen. Den fungerar som en identitetsleverantör (IdP) som använder SAML 2.0 för att tillämpa tvåfaktorsautentisering (2FA) innan åtkomst beviljas. Duo utvärderar användar-, enhets- och nätverkskontext mot konfigurerbara policyer för att tillåta eller neka åtkomst, vilket förbättrar säkerheten utöver bara användarnamn och lösenord. Duo erbjuder även flexibla policykontroller, som att kräva MFA vid varje inloggning för vissa appar och mer sällan för andra.
Fördelarna med Cisco Duo inkluderar:
-
Utökad säkerhet: Lägger till nätfiskeresistent MFA för att skydda åtkomst, vilket minskar risken från komprometterade lösenord.
-
Flexibla policyer: Tillåter detaljerad kontroll över autentiseringskrav per applikation eller användargrupp.
-
Integration med befintliga kataloger: Stöder lokala AD, OpenLDAP, molnkataloger och olika SSO-leverantörer, vilket minimerar infrastrukturförändringar.
-
Användarbekvämlighet: Stöder enkel inloggning (SSO) för att minska lösenordströtthet genom att låta användare logga in en gång och få säker åtkomst till flera resurser.
-
Betrodda slutpunkter: Stöder enhetsförtroende för klienter på Windows och macOS, vilket förbättrar säkerhetsställningen.
-
Självbetjäningsregistrering: Inbyggd registrering och duo-prompt förbättrar användarupplevelsen under MFA-installationen.
Duo MFA med SSO utnyttjar befintliga kataloger som Active Directory och OpenLDAP, eller molnidentitetsleverantörer, för att autentisera användare. Duos roll är att tillhandahålla en stark, policydriven andra autentiseringsfaktor integrerad genom SAML 2.0, vilket förbättrar säkerheten samtidigt som användarvänligheten bibehålls genom SSO. Fördelarna inkluderar förbättrad säkerhetsställning, flexibel policytillämpning, sömlös integration och en bättre användarupplevelse.
Cisco rekommenderar att implementera SSO för användare. För förbättrad säkerhet rekommenderas integration med Cisco Duo.
Företagsstrategin för IAM och SSO bör implementeras innan övergången från till . påbörjas.
Funktioner
har ett komplett utbud av kärnfunktioner som ingår i tjänsten. Detta inkluderar många samtalsfunktioner i företagsklass som har funnits tillgängliga i många år. Du kanske inte ser 100 % paritet mellan funktioner och funktioner, men som du kan se i bilden nedan är de viktigaste samtalsfunktionerna tillgängliga i .
Förutom de många användarfunktionerna har den kärnfunktioner i systemet som ingår i plattformen. Dessa inkluderar funktioner som automatiska svarare, samtalsköer, samtalsparkering etc. Du kan se alla tillgängliga kärnfunktioner i systemet under Tjänst → Samtal → Funktioner som visas i figur Webex Callings kärnfunktioner.
Autosvar
Den automatiska svarstjänsten möjliggör 24/7 automatisering av hantering av inkommande samtal, vilket möjliggör effektiv samtalshantering utan att en person behöver svara på varje samtal.
Den automatiska telefonisten svarar på inkommande samtal och ger uppringaren en meny med alternativ för vart de vill dirigera sitt samtal. Detta kan vara till en person, en röstbrevlåda eller en samtalstjänst (t.ex. samtalskö). Uppringaren använder telefonens knappsats för att ange numret från den automatiska svarsmenyn.
Den automatiska svararen stöder följande viktiga funktioner:
-
Arbetstider och scheman efter stängningstid
-
Semesterschema
-
Uppringningsmenyalternativ för att dirigera dina kunder dit de behöver gå
-
Anpassa hälsningar
-
Alternativ för att ringa efter namn
-
Alternativ för vidarebefordran av samtal
-
Control Hub-analyser och rapporter.
För mer information, se Hantera automatiska svarstjänster.
Call Park
Samtalsparkering ger användare möjlighet att enkelt parkera ett samtal så att en annan användare enkelt kan hämta det när de är tillgängliga att ta det. Det frigör också användaren som svarade på det ursprungliga samtalet för att ringa eller ta emot andra samtal medan samtalet är parkerat.
Det finns två typer av samtalsparker tillgängliga i :
-
Samtalsparkering direkt - låter vilken användare som helst parkera ett samtal till en annan användares anknytning eller till en samtalsparkeringsanknytning, enligt definitionen av administratören.
-
Samtalsparkeringsgrupp – gör det möjligt för en definierad grupp användare att automatiskt parkera samtal mot tillgängliga parkeringsdestinationer som definierats för gruppen. Dessa destinationer kan vara gruppmedlemmarnas anknytningar eller samtalsparkeringsanknytningar.
Baserat på konfiguration och parkeringstyp kan användare hämta samtal genom att ringa *88+><extension of parked call>, trycka på linjeknappen som är kopplad till samtalsparkeringsanknytningen eller använda en programknapp på sin IP-telefon.
Ett återkallningsalternativ finns tillgängligt för att återkalla ett parkerat samtal efter en viss period till den användare som parkerade samtalet eller till en alternativ användare.
Mer information finns i Hantera samtalsparkering i Control Hub.
Samtalssvar
Med samtalshämtning kan en administratör definiera en grupp användare (medlemmar) som kan svara på ett samtal till en annan medlems telefon. Detta ger en användare möjlighet att svara på samtal när deras lagkamrater är upptagna och inte kan svara på ett inkommande samtal.
Användarna i en grupp måste befinna sig på samma plats.
Användare kan använda antingen eller sin bordstelefon för att svara på ett samtal.
-
:
-
Stöder visuella och ljudaviseringar
-
Meddelande om inkommande samtal
-
FAC-baserad (ringa *98) eller aviseringsröstsamtal
-
Aviseringar om svar på samtal för flera linjer.
-
-
Bordstelefoner:
-
Meddelande om inkommande samtal
-
Ljudsignaler och visuell avisering via handenhetens LED-lampa. 6821 stöder endast ljudsignaler
-
När aviseringstypen som valts i inte är ingen
-
-
Aviseringar om samtalssvar endast för primära linjer.
-
För mer information, se Konfigurera samtalsmottagningsgrupp.
Samtalskö
inkluderar endast röstsamtalsköer som en del av sina kärnfunktioner och alla användare med en professionell licens kan ingå i en samtalskö, agent eller handledare. Den här funktionen gör det möjligt för användare att effektivt interagera med kunder. Samtalsköer stöder en delmängd av några av callcentrets kärnfunktioner, som röstköer, återuppringning, kompetens- eller prioritetsrouting, hantering av agentköer, analyser, rapportering etc.
Ciscos integrering med Microsoft Teams gör det möjligt för agenter att få åtkomst till samtal och funktioner i samtalskön direkt från sin Microsoft Teams-klient.
Samtalsköer har stöd för följande viktiga funktioner:
-
Hälsningar och meddelanden (välkommen, tröst, viskningar etc.)
-
Håll musiken
-
Återuppringning
-
Köledningspolicyer (natttrafik, helgdagar, vidarebefordran)
-
Agentkö login/logout
-
Hantering av agentköstatus
-
eller support för bordstelefon
-
Övervaka, coacha, bryta in eller ta över med hjälp av funktionsåtkomstkoder (FAC) för handledare.
-
(administratörsåtkomst) för:
-
köhantering
-
Agent- och köanalys och rapportering
-
Hantering av köer, agenter och handledare.
-
För mer information, se Konfigurera samtalskö.
har en tilläggsfunktion för kundassistans som ger ytterligare funktioner i samtalsköer och ger agenter och handledare en bättre användarupplevelse inom . För en jämförelse av funktionerna Samtalskö och Kundassistans, se Jämförelse av Webex Calling-funktioner för samtalskö och kundassistans.
Svarsgrupp
Sökgrupper möjliggör dirigering av inkommande samtal till en specifik grupp av användare via ett förutbestämt samtalsrutningsmönster. Detta säkerställer att samtal besvaras av rätt grupp användare eller skickas till en röstbrevlåda för uppföljning.
En stor skillnad mellan samtalsgrupper och samtalsköer är att samtal inte köas i en samtalsgrupp, så om inga användare i samtalsgruppen är tillgängliga för att svara på samtalet kommer det att kopplas bort, skickas till röstbrevlådan eller vidarebefordras till ett annat nummer (användare eller tjänst).
Mer information finns i Hantera sökgrupper i Control Hub.
Driftlägen
Funktionen Driftlägen gör det möjligt för företag att effektivt dirigera samtal till olika destinationer (användare, röstbrevlåda, samtalstjänster som en samtalskö). Vart och när ett samtal dirigeras baseras på ett schema för tid på dygnet och veckodag, och vilken användare som helst kan auktoriseras att hantera dessa lägen (scheman) för att kontrollera ändringar i samtalsdirigeringen.
Som ett exempel kan samtal till en samtalskö dirigeras till en annan samtalskö med agenter i en annan tidszon för att svara på samtal efter stängningstid, under kontorstid dirigeras till lokala agenter och under helgdagar dirigeras till röstbrevlåda för uppföljning efter att agenter återvänt till kontoret.
En behörig användare kan växla mellan dessa olika vidarekopplingsscenarier (lägen) om de behöver ändra vart inkommande samtal dirigeras under en viss period. Dessa användare kan hantera lägena via sina 6800/7800/8800 MPP-telefoner, 9800-telefoner eller i användarhubben på Hantera lägen.
För mer information, se Samtalsdirigering baserat på driftlägen i Webex Calling.
Anropsgrupp (Paging-grupp)
Personsökningsgrupper låter användare ringa ett enkelriktat samtal för att skicka ett ljudmeddelande till en grupp användare. Varje grupp kan innehålla upp till 75 målanvändare and/or arbetsytor som nås genom att ringa ett fördefinierat nummer eller en anknytning.
När en användare ringer en personsökargrupp görs ett samtidigt samtal till alla tilldelade mål i gruppen, varefter den som ringer kan tala in sina meddelanden och lägga på när de är klara.
Mer information finns i Konfigurera en personsökningsgrupp i Control Hub.
Inspelningar
stöder inspelning av samtal som görs eller tas emot av en användare. Detta kan krävas för kvalitets-, säkerhets- eller utbildningsbehov. Som standard spelas samtal in i , men andra tredjepartsleverantörer av inspelningar kan också användas om andra inspelningsfunktioner eller efterlevnads- och regelkrav krävs.
När den används som inspelningsplattform hanteras alla inspelade samtal i . Fullständiga administratörer med rollen som Compliance Officer kan spela upp och ladda ner inspelningarna. Utan rollen som Compliance Officer kan administratören bara radera inspelningarna.
För mer information om den här funktionen och en lista över inspelningar från tredje part, se Hantera samtalsinspelning för Webex Calling.
Single Number Reach
Räckvidd för ett enda nummer gör att samtal till en användares telefonnummer kan ringa till flera enheter. Detta kan inkludera andra bordstelefoner såväl som mobiltelefoner. Samtal kan också ringas från dessa enheter och användare kan pusha och ta samtal mellan dem.
För mer information om den här funktionen och hur en administratör konfigurerar den i Konfigurera nåbarhet med ett enda nummer (kontoret var som helst).
För mer information om hur en användare kan hantera och konfigurera den här funktionen för sig själv i Webex användarhubb (portal), se Konfigurera nå ett enda nummer (kontor var som helst).
Röstbrevlådegrupp
Röstbrevlådegrupper möjliggör en delad röstbrevlåda som kan tilldelas en användare eller en funktion för samtalsdirigering. Några av anledningarna till att en röstbrevlåda kan behövas är:
-
Allmän röstbrevlåda för en avdelning eller arbetsgrupp
-
Lägg till röstbrevlåda till en automatisk svarsgrupp eller sökgrupp
-
Så här skickar du överfyllda samtal från en samtalskö
-
Användare som bara behöver en röstbrevlåda.
För mer information, se Hantera en delad röstbrevlåda och inkommande faxlåda för Webex Calling.
Attendant Console finns listat på sidan Samtalsfunktioner i Webex, men det är en tilläggsfunktion som kräver köp av licensen för att kunna användas.
För mer information, se Kom igång med Attendant-konsolen.
För information om alla funktioner, inklusive vissa tilläggsfunktioner, se Funktioner tillgängliga efter licenstyp för Webex Calling.
Implementera
Nätverksberedskap
Det första steget i övergången till är att säkerställa en pålitlig och säker internetanslutning mellan det lokala nätverket och molnet.
Eftersom de flesta organisationer ansluter till internet via en eller flera brandväggar eller säkerhetsenheterär det viktigt att validera att de nödvändiga trafikflödena stöds.
Nätverks- och säkerhetsadministratörer måste förstå dessa flöden vad gäller:
-
Riktning (inkommande vs utgående)
-
Protokoll (Exempel - SIP TLS, SRTP, HTTPS)
-
IP-adressintervall som används av tjänster
-
Portnummer som måste öppnas eller tillåtas.
Detta säkerställer att företagets brandväggar, NAT-enheter och annan nätverksinfrastruktur är korrekt konfigurerad för att hantera trafik samtidigt som företagets säkerhetspolicyer upprätthålls.
För information om nödvändiga flöden, inklusive IP-adress, portar och protokoll, se Portreferensinformation för Webex Calling. Använd den här informationen för att konfigurera brandväggen, proxyservrar och annan nätverksinfrastruktur i den befintliga distributionen för att aktivera nätverksflöden.
Decentraliserad internetuppkoppling från varje filial eller plats är den rekommenderade metoden för molnbaserade samarbetstjänster som . Genom att tillåta trafik att lämna lokalt, gör den här modellen följande:
-
Minskar tur- och returfördröjningar och jitter, vilket förbättrar den totala samtalskvaliteten
-
Skalas effektivt i takt med att fler användare och webbplatser övergår till
-
Fungerar sömlöst med SD-WAN, som dynamiskt kan dirigera sessioner till närmaste molningångspunkt för optimal prestanda
- Gör det möjligt att spåra användarnas plats baserat på deras offentliga IP-adress, vilket hjälper till med analys av mediesökvägar och felsökning.
Dessutom måste organisationer säkerställa tillräcklig internetbandbredd på varje plats. Bandbredden bör dimensioneras baserat på det förväntade antalet samtidiga samtal, den valda kodeken (t.ex. Opus eller G.711), plus overhead för signalering, återutsändningar och tillväxt. Detta överensstämmer med förberedelsefasen i PPDIO-livscykeln och skapar en solid grund för migrering.
Initial konfiguration
Det inledande installationsavsnittet i implementeringsfasen av distributionen är grundläggande för att etablera en välstrukturerad och hanterbar molnanropsmiljö. Det här steget omfattar kritiska uppgifter som att konfigurera organisationen, anskaffa och tilldela licenser samt verifiera och göra anspråk på företagets domäner för att säkerställa korrekt användarhantering och säkerhet. Dessutom inkluderar det etablering av licensmalla för att automatisera tilldelning av användarlicenser, konfigurering av enkel inloggning (SSO) för att effektivisera användarautentisering och förbättra säkerheten, samt justering av tjänst- och klientinställningar så att de överensstämmer med organisationens policyer och användarbehov. Genom att slutföra dessa initiala installationsaktiviteter säkerställs att miljön är korrekt konfigurerad för skalbarhet, säkerhet och en sömlös användarupplevelse, vilket banar väg för efterföljande distributions- och driftsfaser.
Domänverifiering
För att kunna identifiera användare som är registrerade med ditt företags e-postdomäner på , är det viktigt att verifiera dina domäner. Utan domänverifiering kommer användarna att tilldelas en konsumentorganisation, vilket komplicerar användarhanteringen för ditt företag. Domänverifiering är ett obligatoriskt steg som gör det möjligt för din organisation att effektivt göra anspråk på och hantera dessa användare.
Se till att alla domäner som är kopplade till dina användares e-postadresser är verifierade. Domänverifiering är inte exklusiv; samma domän kan verifieras i flera organisationer.
För mer information om hur du hanterar domäner, se Hantera dina domäner.
Gör anspråk på (konvertera) befintliga användare
När du har verifierat dina domäner kan du fortsätta att göra anspråk på användare som har registrerat sig för att använda ditt företags e-postdomäner i din organisation. Denna process konsoliderar alla användare under ett enda organisatoriskt paraply, vilket möjliggör centraliserad hantering och effektiviserad administration. Genom att göra anspråk på dessa användare säkerställer du att ditt företag har full kontroll över användarkonton, vilket gör att du kan tilldela lämpliga licenser, konfigurera tjänster och effektivt tillhandahålla nödvändig support. Denna enhetliga hanteringsmetod förbättrar säkerheten, förenklar användarprovisionering och säkerställer konsekvent åtkomst till tjänster i hela organisationen. Att göra anspråk på användare förhindrar också att de hanteras i externa organisationer eller konsumentorganisationer, vilket bibehåller organisationens integritet och kontroll över samarbetsresurser.
För mer information om hur du gör anspråk på användare, se Gör anspråk på användare till din organisation (konvertera) användare.
Konfigurera och testa katalogsynkronisering
För att möjliggöra sömlös användar- och grupphantering kan du synkronisera användare och grupper från din företagskatalog, antingen Microsoft Entra ID (tidigare Azure AD) eller Microsoft Active Directory (AD), till . Den här processen säkerställer att användaridentiteter och gruppmedlemskap underhålls konsekvent i hela din miljö.
För organisationer som implementerar fasvisa distributioner är det avgörande att kontrollera och begränsa omfattningen av synkroniseringen under de första utrullningarna. Detta minimerar risken för oavsiktliga förändringar och möjliggör riktad testning innan bredare implementering.
Den mest effektiva metoden för att filtrera vilka användare som synkroniseras är att utnyttja medlemskap i kataloggrupper:
| 1 |
Skapa en dedikerad synkroniseringsgrupp: I din företagskatalog (Microsoft Entra ID eller AD) skapar du en säkerhetsgrupp specifikt för synkronisering (till exempel synkroniseringsgrupp). |
| 2 |
Fyll gruppen med målanvändare: Lägg bara till de användare du vill synkronisera (t.ex. en testgrupp under pilotfasen) i den här gruppen. Detta gör att du kan kontrollera noggrant vilka som ingår i synkroniseringsprocessen. |
| 3 |
Konfigurera synkroniseringsavtalet med gruppbaserad filtrering: När du konfigurerar synkroniseringsavtalet i Directory Connector eller Entra ID-provisionering, konfigurera omfånget så att det endast inkluderar användare som är medlemmar i den angivna gruppen.
|
| 4 |
Utöka gruppen efter behov: Allt eftersom du går vidare till bredare distributionsfaser lägger du helt enkelt till ytterligare användare eller grupper i synkroniseringsgruppen. Synkroniseringsområdet utökas automatiskt till att omfatta dessa användare, vilket möjliggör kontrollerad och gradvis utrullning. Exempel på implementeringssteg:
Referenser: Synkronisera Entra ID-användare med Control Hub |
Konfigurera och testa enkel inloggning (SSO)
Enkel inloggning (SSO) förbättrar säkerheten och förenklar användaråtkomsten genom att låta användare autentisera en gång med sina företagsuppgifter och få sömlös åtkomst till . stöder SSO-integration med SAML 2.0-kompatibla IdP:er, inklusive Microsoft Entra ID (tidigare Azure AD), federerade Active Directory (AD)-lösningar och olika tredjeparts-IdP:er.
Vid denna tidpunkt bör den utformade SSO-konfigurationen implementeras och testas.
Referenser:
Integrering av enkel inloggning i kontrollhubben
konfigurera enkel inloggning för WebEx-administration
Anskaffa, tillhandahålla och verifiera licenser
Som en del av den initiala installationen för är det viktigt att anskaffa, tillhandahålla och verifiera lämpliga licenser för att aktivera och hantera tjänster effektivt. Upphandlingsprocessen innebär att välja licenstyper baserat på användarroller och arbetsbelastningar, till exempel Professional-, Standard- och Workspace-licenser. Licenser genereras och tillhandahålls via Ciscos programvaruplattformar eller via partners. Efter anskaffning och tillhandahållande måste korrekta licensantal verifieras i . Denna process säkerställer att organisationen har rätt licenser aktiverade och redo att användas i distributionen.
Som en del av den initiala licensieringsinstallationen i är det viktigt att konfigurera organisationsbaserad automatisk licensiering för att effektivisera licenstilldelningen för nya användare. Den här konfigurationen gör att licenser beviljas automatiskt när användare läggs till i organisationen, vilket eliminerar behovet av manuell licenstilldelning. När du konfigurerar automatisk licensiering på organisationsnivå väljer du de tjänster som ska tilldelas och definierar omfattningen, till exempel att endast tillämpa licenser på framtida användare eller att även inkludera befintliga användare.
Om din distributionsplan istället innebär att automatisk licensiering används på gruppnivå kan du välja att inte tilldela licenser på organisationsnivå för att undvika konflikter eller dubbla licenstilldelningar. Med automatisk licensiering på gruppnivå tilldelas licenser baserat på gruppmedlemskap. Användare i flera grupper får licenser från alla tillämpliga grupptilldelningar.
Gruppbaserad konfiguration av licenstilldelning måste utföras efter att katalogsynkroniseringen har slutförts så att synkroniserade grupper finns och kan användas för licenstilldelning.
Mer specifikt kräver automatisk licenstilldelning ytterligare provisioneringsinformation, såsom användarplats och tilldelning av telefonnummer. Användarens arbetstelefonnummer måste vara i +E.164 format, förprovisionerat och tilldelat en giltig plats för att licensen ska aktiveras automatiskt. Om dessa villkor inte är uppfyllda kommer användaren inte att tillhandahållas med tjänster automatiskt och kan kräva manuell åtgärd.
Sammanfattningsvis, konfigurera organisationsbaserad automatisk licensiering för nya användare om du vill ha en bred, organisationsomfattande licenstilldelning. Om du föredrar mer detaljerad kontroll eller har olika licensbehov per grupp, konfigurera automatisk licensiering på gruppnivå och undvik att tilldela licenser på organisationsnivå för att förhindra överlappning och säkerställa korrekt licenshantering.
Inställningar för Webex Calling-tjänsten
Det är viktigt att genomföra en omfattande granskning och konfiguration av de globala tjänsteinställningarna inom .
Börja med att gå till och navigera till inställningsavsnittet. Granska noggrant varje konfigurerbart alternativ, inklusive, men inte begränsat till, konfiguration av intern uppringning, parametrar för nödsamtal, policyer för samtalsdirigering, hantering av röstbrevlåda och enhetens standardinställningar.
Justera dessa globala inställningar så att de återspeglar din organisations policyer och designbeslut.
Även konfigurationsinställningar och användar- och appmallar.
Pilotmigrering
Under implementeringsfasen representerar genomförandet av en pilotmigrering en kritisk milstolpe i valideringen av övergången från till . Detta pilotprojekt innebär att en representativ delmängd av användare på en eller flera platser etableras på plattformen, vilket säkerställer att den valda populationen återspeglar olika användningsfall och organisatoriska roller. Parallellt med användarmigreringen måste viktiga samarbetstjänster, inklusive röstbrevlåda, automatiska svarstjänster, samtalsköer och sökgrupper, överföras till sina motsvarigheter för att upprätthålla affärskontinuitet och tjänstefunktionalitet.
Pilotmigreringen bör utnyttja samma kombination av Cisco-baserade verktyg och tredjepartsmigreringsverktyg som planeras för den bredare organisationsdistributionen, vilket säkerställer att processerna, automatiseringsarbetsflödena och integrationspunkterna valideras noggrant under representativa förhållanden.
De primära målen med denna pilotutplacering är tvåfaldiga: för det första, att validera och förfina de heltäckande övergångsprocesserna, inklusive arbetsflöden för användarprovisionering, datamigreringsprocedurer och slutpunktskonfigurationer; och för det andra, att heltäckande verifiera funktionaliteten hos migrerade tjänster under verkliga driftsförhållanden.
Denna etappvisa metod gör det möjligt för projektgruppen att identifiera och åtgärda eventuella tekniska eller procedurmässiga problem i en kontrollerad miljö, samla in användarfeedback om den nya plattformsupplevelsen, bedöma effektiviteten hos valda migreringsverktyg och skapa förtroende för migreringsmetodiken innan de fortsätter med en bredare organisatorisk implementering.
Insikterna som erhållits under denna pilotfas är avgörande för att optimera efterföljande migreringsvågor och säkerställa en smidig och riskreducerad övergång för hela företaget.
Anskaffa PSTN
För att upphandla PSTN-tjänster för , välj först ett PSTN-anslutningsalternativ i .
Om en organisation planerar att upprätthålla hybrid dubbel samtalskontroll ( fas 1 i figur Fasvis övergång till samtal: Hybrid och moln) antingen tillfälligt eller på obestämd tid, kommer de att behöva distribuera en eller flera lokala gateways för lokala PSTN för att tillåta samtal mellan och slutpunkter.
Om en fullständig övergång ( fas 2) till molnet är slutmålet, inklusive PSTN, krävs antingen ett Cisco-samtalsplan eller ett Cloud Connect-alternativ för PSTN.
Samarbeta med din valda leverantör för att beställa och portera telefonnummer innan du konfigurerar dem i . Att beställa telefonnummer eller initiera portordrar är endast required/possible för lokal PSTN och Cloud Connect för . För Cisco Calling Plans initieras beställning och portering inifrån Control Hub så snart platsen har skapats, och i länder där Cisco Calling Plan är tillgängligt. För mer information om Cisco Calling-abonnemang, se Komma igång med Cisco-abonnemangen.
Som en del av PSTN-implementeringen, se till att din leverantör har aktiverat både inkommande och utgående PSTN-tjänster för din plats. Utför dessutom testsamtal för att verifiera att samtal dirigeras korrekt via din valda PSTN-anslutning.
Konfigurera platser
Innan du lägger till användare och enheter till måste du etablera samtalsplatser. För varje plats måste en giltig gatuadress anges. I USA och Kanada valideras och används denna adress av plattformen för att skicka PIDF-LO-platsinformation för nödsamtal.
När du konfigurerar platser som använder lokalt PSTN måste du konfigurera de lokala gatewayerna därefter. I måste en trunk och en ruttgrupp skapas för varje lokal gateway, och ruttgruppen tilldelas sedan som PSTN-val för platsen. Cisco rekommenderar starkt att alltid välja en ruttgrupp som PSTN-val, eftersom den här metoden gör att du enkelt kan lägga till ytterligare trunkar i framtiden, vilket stöder både skalbarhet och redundans. Cisco rekommenderar också att aktivera dubbel identitet och stöd för P-Charge-Info på varje PSTN-trunk, eftersom detta förenklar identifieringen av den fakturerbara parten för utgående direkta eller vidarekopplade samtal. Om din PSTN-leverantör använder en annan rubrik för fakturering kan du kopiera informationen från P-Charge-Info-rubriken på den lokala gatewayen till den faktureringsrubriken som krävs.
För platser som använder Cloud Connect eller Cisco Calling Plan som PSTN-alternativ, välj helt enkelt respektive PSTN-alternativ för platsen under installationen. Om platsen använder antingen Cloud Connect för eller lokalt PSTN måste du lägga till telefonnumren som beställdes i föregående steg. Nummer kan läggas till som inaktiva om du inte vill att de ska inkluderas i samtalsdirigering direkt; du kan aktivera dessa nummer senare när de tilldelas användare eller funktioner.
Det är viktigt att alltid ange huvudnumret för varje plats. Huvudnumret kan tilldelas antingen en användare eller en funktion, till exempel en automatisk svarare. För att aktivera röstbrevlåda på platsen, se till att ange pilotnumret för röstbrevlådan, även känt som röstportalnumret.
Ytterligare inställningar för att ringa platser inkluderar konfigurering av nödsamtal, till exempel nödnummer för återuppringning, aviseringsalternativ och förbättrade funktioner för nödsamtal. Du bör också granska och justera inspelningsinställningar, språkinställningar och enhetskonfigurationer efter behov för varje plats. Om din organisation använder förkortad intern uppringning på nätet med företagsnummer (significant numbers), kom ihåg att konfigurera en unik platskod för platsen i de interna uppringningsinställningarna. Slutligen, om extern uppringning kräver en utgående siffra, se till att ställa in detta i inställningarna för extern uppringning. När en utgående uppringningssiffra har konfigurerats rekommenderar Cisco att aktivera tillämpning av utgående uppringningssiffror för att säkerställa konsekvens.
Integrering med lokal samtalskontroll
För att integrera med lokal samtalskontroll är det nödvändigt att konfigurera trunkar, ruttgrupper, företagsuppringningsplaner och både plats- och globala inställningar. Börja med att konfigurera trunkarna och lokala gateways som är avsedda för sammankoppling med det lokala samtalskontrollsystemet; detta steg krävs endast om dedikerade trunkar behövs. Om befintliga trunkar och ruttgrupper är tillräckliga för din distribution kan de återanvändas för den lokala sammankopplingen utan ytterligare konfiguration.
När trunkarna och ruttgrupperna har upprättats, fortsätt med att skapa företagets uppringningsplaner och tilldela lämplig ruttgrupp som destination för varje uppringningsplan. När integrationen involverar flera lokala samtalskontrollsystem som är anslutna via olika trunkar, krävs flera uppringningsplaner. Det är viktigt att säkerställa att dessa uppringningsplaner endast innehåller de mönster som krävs för att dirigera samtal till lokala destinationer.
Om din distribution kräver stöd för routning av okända tillägg bör den här funktionen aktiveras på platsnivå. Dessutom, när routning av okänd anknytning är aktiverad, måste du ange den maximala okända anknytningslängden i avsnittet Samtalsrouting mellan och lokaler i inställningarna för samtalstjänster i . Detta säkerställer sömlös samtalsdirigering och korrekt hantering av anknytningsbaserade uppringningsscenarier i din integrerade miljö.
Migrera användare i omgångar
När du migrerar användare från till kanske du inte kan flytta alla användare samtidigt. Detta kan bero på flera orsaker, inklusive men inte begränsat till antalet webbplatser eller användare, hur lång tid det tar att överföra en webbplats and/or grupp av användare samtidigt, begränsade IT- eller webbplatsresurser för att stödja ändringsfönstret, ändringsfönstrets varaktighet, ändringens komplexitet etc.
När du migrerar användare i faser är det viktigt att identifiera vilka användare som behöver migrera tillsammans i samma batch. Det primära målet är att migrera samman användare som har beroenden av varandra för sina samtalstjänster och funktioner. Du vill se till att alla deras samtalsfunktioner (exempel - samtalsköer) är fullt fungerande precis som de var före övergången.
Även om du implementerar samtalskommunikation mellan och med lokala gateways kan du inte dela delade tjänster eller funktioner över den här anslutningen. Därför behöver du identifiera beroenden mellan användare genom att titta på funktioner som:
-
Övervaka andra användare med hjälp av BLF:er
-
I samma pilotsökning, anropskö osv.
-
Delad linje
-
Använda samtalshämtning
-
Använda samma samtalsparkeringsnummer
-
Snabbtelefon
-
Executive/Admin.
Ett exempel skulle vara en användare som är en del av en jaktgrupp som övergår till . Den här användaren kommer att övergå till med jaktgruppen och med alla andra medlemmar i jaktgruppen. Därför kan Hunt Group och dess medlemmar efter övergången framgångsrikt svara på samtal på den nya plattformen.
Detta blir mer utmanande när användare är anslutna till olika användargrupper för olika samtalstjänster och funktioner. Detta kommer att kräva att mer än en grupp användare och en anropstjänst överförs samtidigt.
Använd utdata från Migration Insights-verktyget eller ett tredjepartsverktyg som du använde i förberedelsefasen för att avgöra vilka användare och funktioner som ska grupperas tillsammans. Denna utdata borde ha använts för att utveckla din migreringsplan och kommer att ge dig insikter i hur du grupperar användare och funktioner som behöver övergå tillsammans.
De viktigaste stegen vid överföring av en grupp användare är:
-
Identifiera användare som ska migreras tillsammans
-
Verifiera att alla användare är inne
-
Verifiera att alla TN:er för användarna finns i
-
Kontrollera korrekt telefonnummerformat i katalogen
-
Se till att licens- och inställningsmallen för användargrupperna är korrekt konfigurerad.
-
Verifiera eller konfigurera alla samtalstjänster och funktioner för användargruppen (före eller under övergången, beroende på vad som är lämpligt)
-
Lägg till användare i gruppen med samtalsaktiverade användare i företagskatalogen
-
Utnyttja verktyg – verktyg för migrering av användare och funktioner and/or verktyg från tredje part
-
Disable/Delete user/device katalognummer och uppringning features/services efter övergången.
Efter migrering av en grupp användare, testa en delmängd av användarna för att bekräfta att alla deras samtalsfunktioner och tjänster fungerar korrekt. Om samtalsfunktioner som samtalskö, sökgrupper etc. övergår med användargruppen, testa då dessa samtalstjänster för att se till att de fungerar korrekt.
Arbetsytor
I [engelsk text] avser en arbetsyta en delad plats (som ett konferensrum, ett mötesrum eller en hot desk) som kan tilldelas enheter, anknytningar och användare. Till skillnad från traditionella Unifed CM-telefoner är arbetsytor:
-
Platscentrerad: knutna till fysiska utrymmen.
-
Enhetsflexibel: kan ha en eller flera enheter (bordstelefoner, kort, etc.).
När arbetsytor har identifierats som en del av övergången till , kan de läggas till under Enheter. Varje arbetsyta behöver en enhetstilldelning, och om de redan finns i Unified CM måste de återställas eller omprovisioneras. Funktioner som röstbrevlåda, vidarekoppling av samtal och samtalssvar kan aktiveras eller inaktiveras, och principer kan tillämpas för videosamtal, samtalsparkering och mobilitet efter behov. Testa varje arbetsyta genom att ringa interna och externa samtal, testa video-, konferens- och mobilitetsfunktioner. Slutligen, informera användarna om eventuella tillämpliga processer för arbetsyteenheter och bokningar.
För mer information om arbetsytor i , se Arbetsytor.
Provisioneringsenheter
Telefoner som för närvarande är registrerade till måste migreras till som en del av molnövergången. För att göra migreringen så enkel som möjligt med minimal risk för misslyckande rekommenderar Cisco att man migrerar fysiska platser eller avdelningar samtidigt. Du kan dock behöva migrera användare i omgångar på grund av funktionsberoenden. Se avsnittet Migrera användare i omgångar för mer information.
Alla telefoner som stöds och som du behöver övergå från måste konfigureras som en användare eller arbetsyta och den fysiska telefonen måste konfigureras om för att registreras hos . Dessutom behöver telefonerna i 7800- och 8800-seriens firmware uppgraderas från Enterprise-firmware till Multiplatform Phone (MPP). Den här processen inkluderar att ladda övergångs-firmware innan man laddar den MPP-firmware som krävs för registrering. Det kräver också lämplig migrationslicens. Cisco har förbättrat den här processen under de senaste åren för att göra det enklare för dig att uppgradera dina företagstelefoner med firmware till MPP-firmware. För mer information om stegen för att slutföra uppgraderingen av den inbyggda programvaran, se Konvertera Cisco 7800- och 8800-seriens IP-telefoner mellan Enterprise- och MPP-firmware.
Utöver stegen som beskrivs i den här artikeln finns det ett inbyggt verktyg, Migrera din telefon till Webex Calling, som du kan använda för att migrera dina 7800- och 8800-telefoner från Enterprise till MPP-firmware. Det här verktyget låter dig också lägga till telefonerna och tilldela dem till lämpliga användare eller arbetsytor. För mer information om verktygsanvändning, se Migrera din telefon.
För telefoner i 9800-serien som är registrerade med ovanstående krav på migrering av firmware gäller inte. Dessa telefoner kör PhoneOS, som stöds av både och . För att överföra dessa telefoner till dig måste du lägga till dem i Webex Calling, tilldela dem till en användare eller arbetsyta och sedan fabriksåterställa telefonerna. PhoneOS-startsekvens för registrering Figuren nedan visar PhoneOS-startsekvensen och hur telefonen registreras när den har lagts till, även om telefonen fortfarande är provisionerad. and/or DHCP-alternativ (exempel - 150) används.
stöder fabriksåterställning av PhoneOS-enheter för att möjliggöra Zero-Touch-onboarding till . administratörer kan fjärråterställa fabriksinställningarna för 9800- och 8875-telefonerna via CUCM-administrationssidorna, vilket eliminerar behovet av fysisk åtkomst till telefonerna för att onboarda dem till . Den här funktionen stöds med enhetspaketen från och med 9 september 2025:
-
CUCM v15 - Unified Communications Manager version 15
-
CUCM v14 - Unified Communications Manager version 14.
För mer information om registreringsprocessen för 9800-serien, se Registreringsprocess.
Förutom Cisco IP-telefoner kan det krävas att andra enheter tillhandahålls, såsom analoga telefonadaptrar (ATA), trådlösa telefoner (Wifi, DECT), videoenheter, röstgateways och enheter och telefoner fråntredje part . Många av dessa enheter har ingen uppgraderingsväg för firmware, som IP-telefoner, för att övergå från företagsfirmware till molnfirmware. Därför kommer du att etablera var och en av dessa enheter i Control Hub. Vissa av dessa kan inte övergå till och motsvarande modell kommer att behöva ersätta den (t.ex. ATA 191/192) och andra kommer att kräva manuell omkonfiguration and/or programvaruändringar.
- Röstgateways – För att migrera din lokala gateway, se Migrera lokal gateway.
För mer information om hur du konfigurerar din röstgateway VG400, VG410 eller VG420 i Control Hub, se Lokal gateway
-
Analog telefonadapter (ATA) – För att komma igång med din Cisco ATA 191 och 192, se Cisco ATA.
-
Trådlös Wifi-telefon – För att integrera trådlös telefon 840 och 860, se Integrera trådlös Webex-telefon.
-
Trådlösa DECT-telefoner – För att komma igång med din nya Cisco IP DECT 6800-serie, se Cisco IP DECT.
För att bygga och hantera ett digitalt DECT-nätverk i Control Hub, se Hantera DECT-nätverk
För mer information om Cisco IP DECT 6800, se Implementeringsguide
-
Tredjepartsenheter och telefoner - Arbeta medtredjepartsleverantörer på device/phone krav och processen för att migrera eller ersätta dem för att stödja .
Konfigurera funktioner
Alla samtalsfunktioner som krävs måste etableras före eller under övergången. Som diskuterats i avsnittet Migrera användare i batchar måste anropsfunktionerna konfigureras och överföras när de användare som använder dem överförs.
För mer information om hur du konfigurerar varje funktion, se motsvarande konfigurationshjälpartiklar.
-
Automatiska receptionister – För att hantera automatiska receptionister, se Automatiska receptionister
-
Samtalsparkering - För att hantera samtalsparkering, se Samtalsparkering
-
Samtalsmottagning - För att konfigurera samtalsmottagningsgruppen, se Samtalsmottagning
-
Samtalsköer - För att konfigurera samtalskö, se Samtalskö
-
Jaktgrupper - För att hantera jaktgrupper, se Hantera jaktgrupp
-
Driftlägen - För samtalsdirigering baserad på driftlägen, se Samtalsdirigering baserad på driftlägen
-
Personsökargrupper - För att konfigurera en personsökargrupp, se Konfigurera en personsökargrupp
-
Inspelningar - För att hantera samtalsinspelning för , se Hantera inspelningar
-
Räckhåll för ett enda nummer - För att konfigurera räckhåll för ett enda nummer (kontoret var som helst), se Konfigurera ett enda nummer
-
Röstbrevlådagrupp – För att hantera en delad röstbrevlåda och inkommande faxlåda för , se Hantera röstbrevlåda.
Test av accepterande
Acceptanstestning säkerställer att den migrerade miljön uppfyller de funktionella kraven, fungerar som förväntat och ger en sömlös användarupplevelse i alla kommunikationsarbetsflöden. Denna valideringsprocess är mångfacetterad och omfattar allt från användarprovisionering och nummertilldelningar till den operativa prestandan för avancerade samtalsfunktioner.
Det här avsnittet ger exempel och belyser viktiga aspekter att beakta vid acceptanstestning; det är dock inte avsett att fungera som en uttömmande eller heltäckande checklista.
Användarprovisionering och nummertilldelning
En grundläggande aspekt av acceptanstestning innebär att verifiera att alla användare är korrekt och fullständigt provisionerade inom . Detta kräver en noggrann jämförelse mellan källkatalogen () och den nyligen etablerade användarbasen för att säkerställa att varje användarkonto, tillsammans med tillhörande attribut som anknytningsnummer och DID-tilldelningar (direkt inkommande uppringning), har migrerats korrekt. Fullständig etablering är avgörande, inte bara för driften från första dagen utan även för löpande administration och support.
Validering av nummertilldelning inkluderar att bekräfta att varje användare har tilldelats rätt anknytning och externt nummer, och att dessa nummer dirigeras korrekt i både interna (online) och externa (PSTN) samtalsflöden. Det är viktigt att kontrollera om det finns överlappningar, saknade tilldelningar eller felkonfigurationer som kan leda till fel i samtalsrouting eller avbrott i tjänsten.
PSTN-samtalflöden och presentation av nummerpresentation
En robust acceptanstestningsprocedur måste omfatta end-to-end-validering av PSTN-samtalflöden. Detta inkluderar både inkommande och utgående samtalsscenarier. För inkommande PSTN-samtal bör testteamet bekräfta att samtal levereras till de avsedda slutpunkterna, oavsett om det är enskilda användare, samtalsköer, sökgrupper eller automatiska svarare. Utgående PSTN-samtal måste ringas korrekt, med särskild uppmärksamhet på korrekt leverans och presentation av nummerpresentation. Detta innebär att säkerställa att rätt uppringarnamn och nummer visas för externa mottagare, i enlighet med organisationens policyer och myndighetskrav.
Testning bör också ta itu med redundansscenarier, såsom hantering av oåtkomliga slutpunkter eller nätverksavbrott. Detta hjälper till att bekräfta att reservmekanismer och alternativ routing fungerar korrekt, vilket upprätthåller tjänstens kontinuitet och tillförlitlighet.
Samtalsflöden på nätet
Interna samtalsflöden, eller samtalsflöden på nätet, utgör ryggraden i företagskommunikationen. Acceptanstestning inom detta område verifierar att samtal mellan användare inom organisationen dirigeras korrekt, med funktioner som samtalsöverföring, väntekoppling, vidarekoppling och konferenssamtal som fungerar som avsett. Integriteten hos uppringningsplaner, anslutning mellan anknytningar och stödet för organisationens samtalspolicyer måste bekräftas.
Hantering av användarsamtal och funktionsvalidering
En viktig aspekt av acceptanstestning innebär att validera hur användare hanterar samtal med hjälp av och bordstelefoner som stöds. Denna process fokuserar på att bekräfta att de dagliga samtalsflödena är intuitiva och tillförlitliga, och att användarna har sömlös åtkomst till de kärnfunktioner som krävs för deras roller. Testningen bör bedöma hur enkelt användare kan ringa och ta emot samtal, hantera parkerade och återuppta samtal samt utföra både blinda och konsultativa överföringar. Det är också viktigt att kontrollera att vidarekoppling, konferenser och andra avancerade funktioner, som att parkera och hämta samtal eller aktivera störningsfritt läge, är lättillgängliga och fungerar smidigt.
Upplevelsen bör utvärderas med avseende på tydlighet och respons, med hänsyn till hur användare interagerar med samtalshistorik, röstbrevlåda och integrerade kataloger. Ytterligare uppmärksamhet bör ägnas åt möjligheten att flytta aktiva samtal mellan enheter och att effektivt använda samtalskontroller i appen eller på fysiska telefoner. Det yttersta målet är att säkerställa att slutanvändarupplevelsen är konsekvent, effektiv och fullt ut stöder organisationens kommunikationsbehov efter migreringen.
Samtalsköer: Erfarenhet av agent och handledare
Samtalsköer används ofta för att hantera scenarier med stora inkommande samtal. Acceptanstestning fokuserar här på flera dimensioner. Först bör det verifieras att samtal distribueras till agenter enligt den konfigurerade kölogiken, såsom round robin, längsta inaktivitet eller samtidig ringning. Presentationen av köade samtal på agenternas datorer måste granskas för tydlighet och användarvänlighet, vilket säkerställer att agenterna effektivt kan ta emot, vänta och koppla samtal.
För handledare bör skrivbordsupplevelsen utvärderas med avseende på funktioner som realtidsövervakning, samtalsinbrytning och analyser eller insikter i köprestanda. Detta inkluderar men är inte begränsat till validering av dashboards och rapporteringsverktyg som tillhandahåller användbar data om samtalsfördelning, agentaktivitet och kömatifikationer.
Jaktgrupper: Samtalsfördelning
Sökgrupper är en viktig mekanism för att distribuera samtal till fördefinierade användargrupper. Acceptanstestning måste bekräfta att samtal dirigeras till gruppmedlemmar baserat på den konfigurerade sökalgoritmen, och att scenarier som överflöde, vidarebefordran och inget svar hanteras enligt design. Att säkerställa att gruppmedlemskap och samtalsrutningsbeteenden matchar de som tidigare etablerats i är avgörande för driftskonsekvens och användarnöjdhet.
Automatiska svarare: Meddelanden och menyfunktioner
Automatiska telefonister representerar frontlinjen inom automatiserad samtalshantering. Testningen måste omfatta uppspelning av meddelanden, noggrannheten hos inspelade hälsningar och menyträdens korrekta funktion. Menyvalen bör på ett tillförlitligt sätt dirigera uppringare till rätt avdelningar, individer eller externa nummer. Testning bör också inkludera ogiltiga scenarier eller timeout-scenarier för att bekräfta att uppringare får tydlig vägledning eller omdirigeras som avsett.
Röstbrevlådans funktion
Slutligen är röstbrevlådans funktionalitet avgörande för användarupplevelsen. Acceptanstester bör verifiera att röstbrevlådor är korrekt tilldelade och tillgängliga, både inifrån organisationen och på distans. Möjligheten att spela in, hämta och hantera meddelanden måste bekräftas, tillsammans med leverans av aviseringar.
Optimera
PSTN-migrering till Cloud Connect för
När alla slutpunkter och användare har migrerats till molnsamtal är det enda syftet med Unified CM att fungera som en övergång mellan PSTN-gatewayerna och via den lokala gatewayen. Att ta bort PSTN-gatewayer och lokal gateway från bilden genom att använda Cloud Connect som PSTN-åtkomst för alla Webex Calling-användare har flera fördelar, inklusive kostnadsminskning och förbättrad tillförlitlighet. För att överföra lokal PSTN-åtkomst till Cloud Connect för [tjänster], följ dessa steg:
-
Cloud Connect för partnerval.
Se listan över Cloud Connect-partners och välj bland de tillgängliga partnerna för din organisations plats.
-
Cloud Connect för validering.
Innan PSTN-åtkomst för platser byts till Cloud Connect bör anslutningen till PSTN via den valda Cloud Connect-partnern verifieras och valideras. För detta ändamål måste en testplats provisioneras med några testanvändare provisionerade på den testplatsen. PSTN-åtkomst för den här testplatsen ställs sedan in på Cloud Connect-partnern innan PSTN-anslutningen valideras med testtelefonerna. Efter lyckad validering kan testplatsen avprovisioneras.
-
Nummerportering.
För att förbereda övergången till Cloud Connect måste en porteringsorder göras för alla nummer som för närvarande är tilldelade PSTN-trunken och avslutas den. Alla nummer måste porteras till Cloud Connect-partnern. För att upprätthålla tillgängligheten mellan platser måste alla nummer från alla platser porteras samtidigt.
-
Byt till Cloud Connect-partner.
Vid datumet för övergången måste PSTN-åtkomst för alla platser ställas in på den molnanslutna PSTN-leverantören, och inkommande och utgående anslutning bör verifieras.
Som diskuterats i PSTN-avsnittet i designkapitlet kan kunder också välja att flytta sin PSTN-åtkomst till Cloud Connect i början av övergången med hjälp av PSTN-trunking för hybriddistributioner. För mer information, se PSTN-trunking för hybrid Webex Calling-distributioner. I så fall sker PSTN-åtkomst via den lokala gatewayen under övergången och efter att alla användare har flyttats finns det inget ytterligare PSTN-relaterat migreringssteg förutom avveckling och lokala gateways.
Optimera lokal infrastruktur
När alla användare har övergått till och alla slutpunkter har övergått till molnregistrering (eller har avvecklats), uppdatera lämplig lokal infrastruktur nu när molnanrop används. Uppdateringar av infrastrukturen inkluderar:
-
Ta bort lokala DNS SRV-poster för samtalskontroll och meddelanden från den/de lokala DNS-servrarna, inklusive cisco_uds._tcp.<domain>, cup_login._tcp.<domain>. Dessa SRV-poster krävs inte längre för klienttjänstidentifiering.
-
Ta bort edge-relaterade DNS SRV-poster från det publika DNS-systemet inklusive collab_edge._tls.<domain>. Dessa SRV-poster krävs inte längre för klienttjänstidentifiering av samarbeten i Edge-tjänster.
-
Uppdatera alla relevanta DHCP-scopes för att ta bort alternativ 66 och alternativ 150 TFTP/boot serveradresser. Dessa omfång krävs inte längre för identifiering och nedladdning av konfiguration för slutpunktsanropskontroll.
-
Update/remove lämpliga uppringningspecialister i Lokalt Gateway/CUBE den rutten anropar till och från Unified CM. Dessa uppringningsmotparter krävs inte längre för lokal samtalsroutning.
-
Ta bort alla virtuella maskiner och klusternoder and/or servrar. Återanvända beräkningsresurser och hårdvara efter behov. Dessa resurser behövs inte längre för samtalskontroll och edge-tjänster.
-
Ta bort alla virtuella maskiner i klusternoden and/or servrar. Återanvända beräkningsresurser och hårdvara efter behov. Dessa resurser behövs inte längre för röstbrevlåda och Unified Messaging-tjänster.
-
Rengöring: Efter migrering av PSTN-åtkomst till molnansluten PSTN kan PSTN-trunkar, PSTN-gateways och lokal gateway avaktiveras.
-
För alla befintliga lokala E911-lösningar, ta bort alla platser eller nummer som har migrerats till och när den fullständiga övergången är klar, ta bort virtuella maskiner eller servrar från applikationen. Återanvända beräkningsresurser och hårdvara efter behov. Dessa resurser behövs inte längre för nödsamtal och lokaliseringstjänster.
-
DN:er som tillhör migrerade användare bör placeras i en dold partition för att undvika fel vid samtalsrouting och för att säkerställa att alla CSS:er har prioriterad åtkomst till molnsökvägen för samma DN:er.
-
Uppdatera den fysiskt dispatchbara platsen och nätverkselementet i Horizon Mobility närhelst ändringar sker. Vanliga aktiviteter som kräver uppdateringar är:
-
Byte av nätverksswitch
-
Byte av trådlös åtkomstpunkt
-
Ändringar i DHCP-omfattning
-
Fysiska förändringar inuti byggnaden (om man beslutar sig för att cubical/office)
-
Fysisk utbyggnad eller minskning av kontorsutrymme inuti en byggnad.
-
Använd analyser och felsökning
tillhandahåller omfattande analys- och felsökningsfunktioner som hjälper dig att visualisera och spåra din distribution. Dessa täcker mediekvalitet, detaljerad samtalshistorik, samtalskö, sökgrupp och analys av automatiska svarstjänster. Ett exempel på mediekvalitetsanalys visas i figur mediekvalitetsanalys.
Under felsökning kan varje samtal som görs med hjälp av visas med detaljerad information om viktiga problem relaterade till mediekvalitet och signalering för att hjälpa till att identifiera medieproblem samt misslyckade samtal, som visas i figur felsökning av mediekvalitet.
Felsökning kan också integreras med andra Cisco-produkter som ThousandEyes och Meraki-switchar för att ge en ännu rikare integrerad upplevelse i Control Hub. För mer information om hur du använder Webex Calling analyser och felsökning, se Felsök Webex Calling-samtal i Control Hub.