Tak for din feedback.

I installationsmodellen for et enkelt sted, hvor en ESN (Enhanced Survivalability Node) er implementeret på et websted sammen med en lokal gateway til PSTN-opkaldsrouting. Højst 7500 enheder kan registreres til ESN under en afbrydelse.

I implementeringsmodellen med flere steder, hvor der er flere steder, og ESN kan implementeres på hvert sted, afhænger forretningskravet for webstedets overlevelsesevne. Kravene til en lokal gateway og DNS er altid en nødvendighed, og i alt 8 ESN-noder kan føjes til en Unified CM klynge.

Denne implementeringsmodel er relevant for en kunde på tværs af en region med flere steder, og overlevelsesevne er et krav for flere af disse websteder. Selvom det er muligt at dele den lokale PSTN-gateway på tværs af websteder, anbefales det ikke. hvis der er et netværksafbrydelse, kan webstedet blive isoleret, og i så fald vil ESN ikke være i stand til at nå den lokale gateway for at dirigere opkaldene til PSTN.

Nedenfor er to installationsindstillinger for en udrulning på flere steder:

• Mulighed 1: Forbedret overlevelsesnode implementeret på hvert sted.

• Mulighed 2 - Fælles forbedret overlevelsesknude delt mellem flere websteder.

Vi overvåger og administrerer Enhanced Survivalability Node ligesom andre noder, der er implementeret i Dedicated Instance-datacenter. Under en overlevelseshændelse, når ESN afbrydes fra, Cisco Cloud er det, når vi mister adgangen til noden og automatisk opretter forbindelse tilbage, når afbrydelsen er løst, og forbindelsen gendannes.

Vi administrerer UC-applikationscertifikaterne, og under aktiveringen af Enhanced Survivalability Node opdaterede vi, at Dedicated Instance- Unified CM klyngecertifikatet opdateres med ESN.

Under overlevelsesbegivenheden gemmer Enhanced Survivalability Node alle CDR/CMR-data lokalt. Når forbindelsen gendannes, synkroniseres dataene tilbage til Dedicated Instance Unified CM Publisher. Mængden af data, der kan gemmes, er baseret på diskstørrelsen på den daværende Enhanced Survivalability Node. Den maksimale diskallokeringsplads, der kan indstilles til CDR, er 3328 MB. Dette kan være med lille til stor CDR-filstørrelse baseret på det CDR-interval, der er konfigureret. Udrensningen sker baseret på:

• Når diskforbruget overstiger den tildelte eller konfigurerede diskplads, sletter den de behandlede poster. Hvis diskforbruget stadig er større, er det, når de ubehandlede poster også ryddes.

• Høj vandmærke%, der er konfigureret i indstillingerne „CDR Management“, vil CDR-filerne blive renset. For eksempel, hvis „High Water Mark%“ er konfigureret som 80%, og diskforbruget er 80%, renses CDR-filerne.

• Bevar@@ else af CDR/CMR-filer Varighed (dage), der er konfigureret i indstillingerne for „CDR Management“, vil CDR-filerne blive renset. Som standard er den indstillet til 30 dage.

Følgende er advarslerne i RTMT relateret til Enhanced Survivalability Node:

• SurvivabilityEvent - alarmen udløses, når alle de dedikerede instansnoder ikke er tilgængelige fra den forbedrede overlevelses node.

• RemoteSurvivableNoTreeable - alarmen udløses, når en Enhanced Survivalability Node ikke kan nås fra udgiveren af Dedicated Instance. Unified CM

Under overlevelsesbegivenheden skal du forbinde RTMT til Enhanced Survivalability Node for at overvåge ESN's ydeevne. Det samme vil ikke være tilgængeligt, hvis RTMT er forbundet til de dedikerede instansnoder, da ESN ikke kan nås fra skyen under overlevelsesbegivenheden.

Under normal drift er databasereplikeringen fuldt sammenkoblet mellem alle serverne inklusive Enhanced Survivalability Node i klyngen. Unified CM Da de statiske konfigurationsdata oprettes gennem flytninger, tilføjelser og ændringer, gemmes altid på udgiveren og replikeres én vej fra udgiveren til hver abonnent og knudepunkt for forbedret overlevelsesevne i klyngen.

Under en overlevelsesbegivenhed ændres kun de brugervendte funktioner på de enheder, der er registreret i Enhanced Survivalability Node, og de brugervendte funktioner karakteriseres typisk ved hjælp af det faktum, at du kan aktivere eller deaktivere en funktion direkte på deres telefon ved at trykke på en eller flere knapper, i modsætning til at ændre en funktion gennem en webbaseret GUI. Så den forbedrede overlevelsesnode tillader selvpleje og webadmin GUI som skrivebeskyttede operationer. Brugerens enheder, der er registreret i ESN, er i stand til kun at foretage ændringer i de brugervenlige funktioner, der er anført nedenfor under failover. Disse ændringer synkroniseres dog ikke tilbage til DI- Unified CM udgiveren, når forbindelsen genoprettes.

Brugervendte funktioner er alle funktioner, der kan aktiveres eller deaktiveres ved at trykke på knapper på telefonen og omfatter følgende:

• Videresend alle opkald (CFA)

• Privatliv Aktiver eller deaktiver

• Forstyr ikke (DND) Aktiver eller deaktiver

• Cisco Extension MobilityLogin

• Hunt-group Login eller Log ud

• Enhedsmobilitet

• CTI CAPF-status for slutbrugere og applikationsbrugere.

Godkendelsen af bløde klienter (Cisco Jabberog Webex-applikation) til login under failover til Enhanced Survivalability Node er som følger:

1. Lokal godkendelse: Når godkendelse af brugere udføres lokalt inden forUnified CM, under overlevelsesbegivenheden, vil den forbedrede overlevelsesnode være i stand til at godkende de klienter, der er registreret til den.

2. LDAP-godkendelse: I dette tilfælde udføres godkendelsen af brugere ved hjælp af den lokale LDAP-server. Derefter fungerer godkendelsen af bløde klienter under overlevelsesbegivenheden, forudsat at LDAP-serveren er tilgængelig fra Enhanced Survivalability Node.

   Du bør sikre, at LDAP-kataloget er tilgængeligt for ESN under hele overlevelsesbegivenheden.

3. SSO@@ -godkendelse (Single Sign On): SSO-login-godkendelsen af brugere udføres ved hjælp af IDP-serveren. Derefter fungerer godkendelsen af bløde klienter under overlevelsesbegivenheden, forudsat at IDP-serveren er tilgængelig fra Enhanced Survivalability Node.

   For SSO-aktiveret Unified CM webbrugergrænseflade-login kræves IDP-tilgængeligheden, eller det gendannelsesbaserede URL-login skal bruges.

   Allerede godkendte klienter er fortsat logget ind, da godkendelsen er baseret på det token, der er opnået før overlevelsesbegivenheden. For nye logins, når klienten ikke har et gyldigt token fra tidligere godkendelse, vil ESN imidlertid omdirigere til IDP-serveren til godkendelse. Derfor er det altid nødvendigt at sikre, at IDP-serveren er tilgængelig til ESN under hele overlevelsesbegivenheden.

Medieressourcer er nødvendige for grundlæggende Unified CM funktioner, såsom Music on Vent, Announcement, Conference Bridge (software) -tjenester, skal være aktiveret på ESN. Hvis hardwarebaserede medieressourcer blev implementeret, skal du under overlevelseshændelsen sikre dig, at medieserverne er tilgængelige fra ESN.

Under normal drift af DI- Unified CM klyngen dirigeres nødopkaldene (især i AMER-regionen) gennem RedSky-skyen, hvor der er en SIP-trunk, der er konfigureret mellem den dedikerede Instnace-samlede CM-klynge og RedSky-skyen.

Hvis der er en overlevelseshændelse, kan RedSky-skyen ikke nås fra ESN, og det er derfor nødvendigt for dig at konfigurere nødopkaldsplanen således, at hvis RedSky ikke er tilgængelig, skal du dirigere nødopkaldene gennem den lokale PSTN GW, der er konfigureret på det pågældende sted. Rutegruppen skal bestå af den lokale PSTN GW til at håndtere opkaldsdirigering under overlevelsesbegivenheden.

Konfigurer opkaldsplanen til dirigering af opkald inden-, intersite-, interklynge- og PSTN-opkald under overlevelseshændelsen. Generelt kan ESN kun dirigere opkald til enheder, der er registreret til det. Alle andre opkald skal dirigeres til den lokale PSTN GW (konfigureret på alle steder, hvor ESN er implementeret) og derfra til PSTN. Følgende er nogle få scenarier forklaret:

• Telefon 1 og telefon 2 registreret til samme ESN - Opkaldet dirigeres inden for ESN.

• Telefon 1 registreret til ESN og telefon 2 registreret til Dedicated Instance- Unified CM klynge - Opkaldsplanen skal dirigere opkaldene fra ESN til den lokale PSTN GW, derfra til DI via PSTN. Unified CM Under overlevelsesbegivenheden skal opkaldsplanen registrere opkaldsroutingsfejlen og omdirigere opkaldene gennem den lokale PSTN GW. Det samme bør gælde for indgående opkald til ESN fra DI- Unified CM enheder.

• Telefon 1 registreret til ESN og telefon 2 er en PSTN-enhed: Under overlevelseshændelse skal PSTN-opkald dirigeres til den lokale PSTN-gateway. Du skal sikre dig, at opkaldsplanen har mulighed for at registrere fejl i opkaldsdirigering og omdirigere opkaldet gennem den tilgængelige lokale PSTN-gateway.

• Under overlevelseshændelsen, når forbindelsen fra dit websted til skyen med dedikeret forekomst er nede (WAN- eller forbindelsesafbrydelse), fungerer funktionerne for telefonsvarer og automatisk besvarelse ikke for de enheder, der registrerer sig på ESN, da Cisco Unity Connection serveren er hostet i den dedikerede instance-sky, som forbindelsen fra ESN er nede til. Hvis din enhed er konfigureret med „Opkald videresendt uregistreret (CFU)“, og opkaldet modtages i DIUnified CM, kan den, der ringer, deponere en telefonsvarer i den dedikerede instans Unity Connection. Hvilket kan hentes, når enhederne falder tilbage til DI forenede CM-abonnenter.

• Men under en overlevelseshændelse, når forbindelsen til Dedicated Instance-sky er tilgængelig, men Unified CM klyngen i DI er nede, fungerer telefonsvareren og den automatiske svartjeneste i dette tilfælde for enheder, der er registreret i ESN, da ESN vil have forbindelse til Unity Connection-serveren, der er implementeret i DI-skyen.

Under overlevelsesbegivenheden vil ESN ikke være i stand til at nå Cisco Expressway E & C i DI-sky og omvendt. Så, i dette tilfælde kan MRA-brugerne ikke få tjenesten fra ESN og vil derfor ikke være i stand til at registrere sig. Men hvis MRA-enheden har internet og kan oprette forbindelse til Cisco Expressways i DI-skyen, kan den registrere sig med DI, forudsat at klyng Unified CM en i DI er funktionel.

For at CTI-baserede integrationer kan fungere med Enhanced Survivalability Node, skal du tilføje Enhanced Survivalability Node som en del af CTI's serverliste. CTI-forbedringer er lavet til applikationer, der bruger JTAPI til at tillade Enhanced Survivalability Node som en CTI-server, som applikationen kun kan oprette forbindelse til, hvis de primære eller sekundære CTI-servere på den konfigurerede liste ikke er tilgængelige. Under en normal drift kan CTI-applikationer på stedet oprette forbindelse til de primære og sekundære CTI-servere i DI-skyen, og under overlevelseshændelse kan de oprette forbindelse til Enhanced Survivalability Node for en fortsat CTI-oplevelse. Applikationer skal tilpasse sig de nye API'er som eksponeret over JTAPI-grænsefladen for at sikre, at tilbagefald fra Enhanced Survivalability Node finder sted, når forbindelsen genoprettes.

For mere information om de nye tilføjede API'er, se afsnittet om redundans, https://www.cisco.com/c/en/us/td/docs/ voice_ip_comm /cucm/ /14_0_1/ -unified-jtapi-developers-guide-14/ jtapi_dev -unified-jtapi-developers-guide-1251_chapter_00.html cucm_b_cisco cucm_b_cisco

Tredjepartsapplikationer, der interagerer gennem SIP-trunkerne, understøtter med Enhanced Survivalability Node. I SIP-trunk-konfigurationerne skal konfigurationen „køre på alle noder“ være aktiveret.

Tredjepartsenheder understøttes, som har tertiær TFTP-kapacitet.