# Överväganden för PSTN-integration Denna avdelning gäller kunder som överväger att integrera ZPLS-modulen med en SBC och PSTN-anslutning för ökad överlevnadsförmåga. Kunder som inte planerar att integrera ZPLS-modulen med PSTN-anslutning kan hoppa över denna avdelning utan konsekvenser. ### Överväganden vid SBC-integration #### Krav för SBC För att integrera en SBC med Zoom för överlevnadsförmåga måste en SBC uppfylla följande krav: * TLS 1.2 och SRTP * Stöd för ömsesidig TLS * Session Initiation Protocol (SIP) * DTMF (RFC-2833) * Topology hiding (RFC-5853) * SIP Early Offer (**obligatoriskt**) * Opus, G.711 μ-law, G.711 A-law och G.729-codecs #### PSTN-integrationer kräver en SBC och en pålitlig tredjepartsleverantör För PSTN-anslutning måste kunder tillhandahålla en session border controller (SBC) ansluten antingen till en äldre anslutning eller en SIP-trunk med en mobil- eller alternativ anslutning (t.ex. DSL). Kunder bör tänka på att alla SIP-trunkar som distribueras vid SBC:n kan vara beroende av samma internetanslutning som upplever ett avbrott. På grund av denna möjlighet bör kunder överväga en pålitlig, tertiär anslutning för PSTN-anslutning. #### Valfri Zoom Phone BYOC-certifierad SBC kan användas Vilken session border controller (SBC) som helst som är [certifierad för Zoom Phone](https://support.zoom.us/hc/en-us/articles/360001299063-Zoom-Phone-Certified-Hardware#h_ec5008d4-3581-46e7-a06d-32599511d089) kan också användas med ZPLS-modulen. Kunder på en befintlig Zoom Phone BYOC-plan kräver ingen ytterligare eller separat SBC för överlevnadsändamål. #### Zooms DigiCert-certifikat måste installeras på SBC:n För att upprätta TLS-anslutning både till ZPLS-modulen och Zoom-molnet måste Zooms [DigitCert root- och mellanliggande certifikat](https://support.zoom.us/hc/en-us/articles/360044092031) vara installerade på SBC:n. #### SBC:er måste dirigera inkommande samtal till Zoom Phone-datacenter som första och andra routningsval, och ZPLS-modulen som tredje Kunders SBC:er måste dirigera inkommande samtal från PSTN till primär och sekundär SIP-zon innan de försöker ZPLS-modulen. Med denna konfiguration kommer samtal endast att dirigeras till ZPLS-modulen under ett överlevnadsfall, eftersom SBC:n och Zoom Phone-datacentren annars bör bibehålla stabil anslutning. Underlåtenhet att följa denna logik kan resultera i leveransfel för samtal, eftersom ZPLS-modulen inte kan routa samtal till molnregistrerade enheter. {% hint style="info" %} När Zoom Phone-molnet blir tillgängligt igen efter ett överlevnadsfall kan en SBC tillfälligt försöka routa BYOC-nummer till Zoom-molnet medan den berörda numrets klientenhet är registrerad till ZPLS-modulen. Om detta inträffar kommer samtalsroutningen att följa inställningarna för [**När ett samtal inte besvaras**](https://support.zoom.us/hc/en-us/articles/360059966372-Customizing-call-handling-settings#h_86f4bf1b-51ea-4d70-9e40-4a84a5ca1c2c) under denna mellanperiod. {% endhint %} #### Utgående samtal från ZPLS-modulen måste routas till SBC och PSTN SIP-trunk När överlevnadsläge är aktivt måste samtal från ZPLS in i SBC:n routas till PSTN SIP-trunken för att etablera externa telefonanslutningar. Alla samtal till nummer som inte är registrerade till ZPLS-modulen skickas till SBC:n konfigurerad för överlevnadsförmåga i E.164-format. ### Överväganden för lokalt vidarekopplad överlevnadsförmåga #### Under ett överlevnadsfall kommer telefonnummer som tillhandahålls av Zoom Phone inte vara externt nåbara om de inte omdirigeras via vidarekoppling Under ett överlevnadsfall kommer telefonnummer som tillhandahålls av Zoom inte vara externt nåbara ur molnets perspektiv. Följaktligen kan användare som befinner sig inom drabbade platser vara otillgängliga om inte samtal till deras primära nummer vidarekopplas till ett alternativt nummer som är associerat med en lokal SBC. {% hint style="info" %} Vanliga exempel på påverkade nummer kan inkludera nummer tilldelade till: användare, gemensamma utrymmen, automatiska receptioner (AR), delade linjegrupper (SLG) och samtalsköer (CQ). {% endhint %} #### Kunder som använder ett lokalt BYOC kräver inte avancerade konfigurationer och kan kringgå vidarekoppling genom att lägga till en tertiär rutt till sin ZPLS-modul från sin SBC Kunder som använder en lokalt baserad BYOC-plan (dvs. kunder som inte använder Zoom Phone-registrerade nummer) kräver inte avancerade konfigurationer för att möjliggöra vidarekoppling. Istället kan BYOC-kunder lägga till en tertiär rutt till ZPLS-modulen från den lokalt baserade SBC:n. #### Vidarekopplingskonfigurationer ställs in av en admin eller behörig användare från webportalen En kontoadmin eller behörig användare kan [konfigurera vidarekopplingslogik](#_1od0waijmvaz) från webportalen genom [manuell inmatning eller en massuppladdning av CSV](#_aezu04x8z043). #### Användare konfigurerade för vidarekoppling kommer att ha tre tilldelade nummer Efter att ha tilldelat ett BYOC-nummer till en användare för vidarekopplingsöverlevnad kommer klientenheten att tilldelas *minst* tre nummer: 1. En intern anknytning med förberäknad site-kod 2. Ett PSTN-nummer som tillhandahålls av Zoom 3. Ett BYOC PSTN-nummer
#### Telefonnummer kan vidarekopplas till maximalt ett BYOC-nummer Varje Zoom Phone-nummer kan vidarekopplas till maximalt **ett** annat BYOC-nummer. Du kan dock vidarekoppla flera telefonnummer till samma BYOC-nummer. Till exempel, om John är tilldelad telefonnumret X55-555-5555 kan Johns telefonnummer vidarekopplas till hans byggnads operatörsnummer på X99-999-9999. På samma sätt kan Johns kollegor också ha sina nummer (X55-555-5554, X55-555-5553 etc.) vidarekopplade till X99-999-9999. Alternativt kan varje användare ha sitt telefonnummer vidarekopplat till ett helt unikt nummer, som X55-555-5554 som routas till X99-999-9998, och X55-555-5553 som routas till X99-999-9997. Dock kan ingen enskild användare ha sitt nummer vidarekopplat både till X99-999-9999 och X99-999-9998. #### Vidarekoppling måste förbli inaktiverat tills ett överlevnadsfall inträffar Även om en administratör kan förkonfigurera vidarekopplingslogik för en plats i förväg, måste vidarekopplingsfunktionen förbli inaktiverad tills ett överlevnadsfall inträffar. Om vidarekoppling är aktiverat under rutinmässig drift kommer alla inkommande samtal till ett Zoom Phone-registrerat nummer att omdirigeras till den lokala SBC:n och det tillhörande BYOC-telefonnumret, vilket kringgår Zoom Phone-tjänster. Därför, för att bibehålla normal Zoom Phone-routning, måste vidarekoppling vara inaktiverat under rutinmässig drift. #### Vidarekoppling kan endast aktiveras av en behörig användare eller admin med fungerande internetanslutning Under ett överlevnadsläge antas en plats internetanslutning vara otillgänglig. Eftersom vidarekoppling måste förbli inaktiverat för standarddrift kan det endast aktiveras av en behörig användare eller admin med en fungerande internetanslutning, såsom en mobil datatjänst eller en alternativ internetanslutning på en annan plats. {% hint style="info" %} För att minimera driftstopp och säkerställa kontinuitet rekommenderar Zoom att företag upprättar pålitliga rutiner för att aktivera vidarekopplingslogik från webportalen under ett överlevnadsfall. {% endhint %} #### Vidarekopplingsregler kan gälla för hela platsen eller för individuella nummer Under ett överlevnadsfall kan en administratör eller behörig användare aktivera vidarekopplingsregler för hela platsen eller för specifika nummer från webportalen. #### När vidarekoppling aktiveras för en användares telefonnummer kommer Zoom inte att ringa användarens molnregistrerade klient, även om den upprätthåller en oberoende molnanslutning När vidarekoppling är aktiverat för ett Zoom Phone-registrerat nummer kommer Zoom inte att försöka routa något samtal till användaren via molnet. Följaktligen, även om en påverkad användare har en molnregistrerad enhet som en mobiltelefon, om telefonnumret är markerat för vidarekoppling kommer alla samtal att routas via PSTN till företagets SBC. Till exempel upplever en plats ett överlevnadsläge och en användares mobiltelefon är ansluten till Zoom Phone-molnet via deras mobiloperatörs dataanslutning. Om en användares telefonnummer är markerat för vidarekoppling, kommer Zoom Phone-molnet **inte** varna deras Zoom Phone-nummer via mobilappen, trots den stabila anslutningen. Istället kommer alla samtal att fortsätta routas via PSTN till kundens SBC. #### Om vidarekoppling inte är aktiverat för en användare under ett överlevnadsfall kommer inkommande samtal att följa varje användares samtalshanteringspreferenser Om vidarekoppling inte är aktiverat under ett överlevnadsfall kommer inkommande samtal att behandlas enligt [samtalshanteringslogiken](https://support.zoom.us/hc/en-us/articles/360059966372-Customizing-call-handling-settings) för varje enskild användare. Om en användare inte har en reservtelefonklient registrerad i molnet, till exempel en mobiltelefon, kommer uppringare att omfattas av reglerna som definieras av **När ett samtal inte besvaras** avsnittet i samtalshanteringspreferenser. #### Vidarekoppling gäller endast för inkommande PSTN-samtal Vidarekoppling för överlevnadsförmåga gäller endast för samtal som routas över PSTN och/eller Zoom Phone-molnet. Samtal som kommer från Zoom-registrerade anknytningar inom samma plats kommer att försöka ansluta via ZPLS-modulen först och PSTN därefter om en SBC är ansluten. Samtal som inte kan ansluta kommer annars att omfattas av behandlingen definierad i **När ett samtal inte besvaras** avsnittet i samtalshanteringsreglerna inom en användares telefoninställningar. ### Flöde för vidarekoppling Följande diagram beskriver logiken för vidarekoppling (när den väl är aktiverad) under ett överlevnadsfall. Denna logik kommer att gälla tills vidarekoppling inaktiveras eller standarddrift återställs. Om vidarekoppling förblir aktiverat *efter* att standarddrift återställts, kommer vidarekopplade samtal att loopas från Zoom Phone-molnet till SBC:n och tillbaka till molnet innan de levereras till användarens enhet. Av denna anledning bör vidarekoppling inaktiveras omgående efter ett överlevnadsfall.
1. En extern uppringare initierar ett samtal till ett Zoom Phone-registrerat nummer och routas över PSTN. 2. Samtalet routas till Zoom Phone-molnet och det slagna telefonnumret identifieras som påverkat av vidarekoppling. {% hint style="info" %} Om vidarekoppling inte är aktiverat kommer Zoom Phone att följa **När ett samtal inte besvaras** logiken för den specifika användaren eller anknytningen. {% endhint %} 3. Eftersom vidarekoppling är aktiverat kommer Zoom inte att försöka avisera användaren utan istället omdirigera samtalet mot det angivna vidarekopplingsnumret över PSTN. 4. Samtalet routas från PSTN till överlevnads-SBC:n. 5. Överlevnads-SBC:n vidarebefordrar samtalet till ZPLS-modulen. 6. ZPLS-modulen vidarebefordrar samtalet till användarens registrerade klient(er), om de är anslutna. ### Överväganden för Emergency Location Identification Number (ELIN) #### En ELIN är ett plats-exklusivt telefonnummer som förmedlar platsinformation till räddningstjänst vid uppringning Ett Emergency Location Identification Number (ELIN) är ett dedikerat telefonnummer som används av Public Safety Answering Points (PSAP) för att identifiera den fysiska adressen till en uppringare när de ringer nödnummer. För denna funktion måste företag samarbeta med sin PSTN-leverantör för att kartlägga en adress till ett telefonnummer för att säkerställa att adressen finns listad i en automatisk lokaliseringsdatabas (ALI) när samtalet tas emot av en PSAP-operatör. Till exempel, tänk på ett universitetscampus som sträcker sig över flera byggnader, där varje byggnad representeras av en separat Zoom Phone-plats. Om en användare ringer nödnummer under ett överlevnadsfall från en telefon eller enhet [associerad med platsen](#_ggwzik1hd9xi), kommer räddningstjänst automatiskt att få den fullständiga adressen som finns registrerad för platsen, förutsatt att platsen är konfigurerad och uppdaterad hos tjänsteleverantören. #### Varje plats kan stödja flera ELIN:er Kunder kan tilldela flera ELIN:er till en plats för en pool av nödnummerresurser. I händelse av en nödsituation under ett överlevnadsfall gör detta det möjligt för flera uppringare att var och en ha en unikt tilldelad ELIN, vilket kan hjälpa räddningstjänst att nå den ursprungliga uppringaren vid återuppringning. Dessutom kan en ELIN tilldelas en användare eller en telefon i ett gemensamt utrymme, vilket ger en mer detaljerad ELIN-tilldelning än på platsnivå och erbjuder en mer exakt plats för räddningstjänst. #### Under ett överlevnadsfall ersätts alla nöd- samtal av ELIN När en användare gör ett nöd-samtal under ett överlevnadsfall kommer användarens uppringande nummer, om ett sådant är tillgängligt, att ersättas med den ELIN som är angiven på platsnivå. Detta gör det möjligt för användare som inte har ett direkt nummer att ringa nödnummer och vara nåbara för återuppringning från nödoperatören. #### Ett ELIN-nummer måste vara ett BYOC-nummer associerat med platsens SBC PSTN-trunk En plats ELIN **måste** vara ett BYOC-nummer som termineras på en PSTN-trunk som är placerad på platsens failover-SBC. Ingen annan typ av nummer kan användas. #### ZPLS-modulen kommer automatiskt att routa samtal från nödleverantörer till ELIN tillbaka till användarens anknytning som ursprungligen ringde i upp till 2 timmar Om en nödoperatör återuppringer till ELIN kommer ZPLS-modulen att routa samtalet tillbaka till den ursprungliga användaren som gjorde nöd-samtalet. ZPLS-modulen kommer att fortsätta routa PSAP-återuppringningar till den ursprungliga uppringaren i upp till 2 timmar. För närvarande är denna funktion begränsad till den första uppringaren. #### När ett telefonnummer har utses som ELIN kan det inte tilldelas till en användare eller en enhet När en administratör har tilldelat ett BYOC-nummer som den angivna ELIN för en plats kan BYOC-numret inte tilldelas någon användare eller annan Zoom Phone-entitet om det inte avassigneras. #### Kunder ansvarar för att underhålla och uppdatera fysiska adresser kopplade till sina ELIN för varje plats Zoom tar inte ansvar för att uppdatera BYOC-operatörer med fysiska adresser som korrelerar till varje ELIN. Kunder ansvarar för att säkerställa att nödadresser är korrekt kartlagda till rätt fysisk adress. ### Överväganden för PSTN-routning #### När överlevnadsläge är aktiv routas mediepacketter genom ZPLS-modulen När överlevnadsläge är aktiverat kommunicerar klienter inte direkt med en SBC eller andra interna klienter; istället förankras eller ”hairpinnas” mediepacketter genom ZPLS-modulen, utan stöd för avlastning av media. Följande diagram visar signal- och mediavägen för aktiva interna och externa samtal.
#### Samtal kommer att försöka routas lokalt först När det är möjligt kommer ZPLS-modulen att försöka routa samtal som härstammar från registrerade Zoom-klienter till lokalt registrerade destinationer. Samtal vidarebefordras endast till SBC:n om destinationen i Request URI-fältet i den inkommande SIP Invite inte matchar en registrerad anknytning. {% hint style="info" %} En registrerad anknytning är en kort anknytning utan site-kod, en lång anknytning med site-kod, ett tilldelat Zoom-registrerat nummer eller ett tilldelat BYOC-nummer. Administratörer bör komma ihåg att ZPLS-modulen uppdaterar dessa data [var tionde timme](#_54gf3fuxcnk5). {% endhint %} #### Under ett överlevnadsfall kommer externa, utgående samtal att visa användarens BYOC-nummer Under ett överlevnadsfall kommer externa, utgående samtal från ZPLS-registrerade enheter att innehålla BYOC-uppringningsnumret. Följande diagram visar samtalsflödet i överlevnadsläge för en användare:
#### Återuppringda samtal kan routas till en användares BYOC-nummer Eftersom externa, utgående samtal som görs under ett överlevnadsfall kommer att använda ett BYOC-nummer, kan externa uppringare återuppringa med hjälp av ett BYOC-nummer istället för en användares Zoom-registrerade telefonnummer. Om överlevnadsfallet är över kommer samtal att routas tillbaka genom molnet [om korrekt routningsprioritet är konfigurerad](#_zgofkpkt74xr). Om händelsen däremot pågår kommer SBC:n att routra samtalet till ZPLS-modulen och den klientregistrerade enheten.
#### Stödda codecs för överlevnadsförmåga Stödda codecs för överlevnadsförmåga är Opus, G.711 μ-law, G.711 A-law och G.729. Transkodning eller transrating av audiocodecs stöds inte. Alla parter i ett aktivt samtal måste stödja samma codec och samplingsfrekvens. ### Överväganden för Survivability Distribution Group Denna avdelning diskuterar överväganden för Survivability Distribution Groups (SDG). Kunder som inte planerar att använda SDG:er eller integrera ZPLS-modulen med PSTN-anslutning kan hoppa över denna avdelning utan konsekvenser. #### Survivability Distribution Groups ger nyanserade alternativ för samtalsroutning under ett överlevnadsfall Survivability distribution groups (SDG:er) ger företag nyanserade alternativ för samtalsroutning — såsom samtalsköer och interaktiva talsvarmenuer (IVR) — under ett överlevnadsfall. Med SDG:er kan företag fortsätta stödja kärntelefontjänster och samtalsroutningskonfigurationer (liknande samtalsköer, automatiska receptionister och delade linjegrupper) tills normal drift återställs. #### SDG:er är inte samma som standarddrifts-distributionsgrupper och måste byggas och underhållas separat Även om SDG:er erbjuder liknande samtalsroutningsfunktionalitet som distributionsgrupper för standarddrift, är SDG:er unika och specifika för överlevnadsfall och måste därför byggas och underhållas separat. Med andra ord, SDG:er **inte** ärver inställningarna eller konfigurationerna för en distributionsgrupp för standarddrift (dvs. samtalskö, automatisk receptionist, IVR osv.) #### SDG:er passar bäst ihop med en BYOC-PSTN-integration och aktiverad vidarekoppling Även om SDG:er kan erbjuda enbart internt stöd (dvs. icke-PSTN-samtal) passar de bäst ihop med en BYOC-PSTN-integration. Med en PSTN-aktiverad SDG kan ett huvudföretagsnummer, när vidarekoppling aktiveras under ett överlevnadsfall, routas till det angivna SDG-telefonnumret och samtalet följa den konfigurerade routingprofilen. Detta gör det möjligt för ett företag att erbjuda en konsekvent samtalsflödesupplevelse för externa uppringare tills normal drift återställs. Följande diagram visar samtalsroutningslogiken för en PSTN-aktiverad SDG:
#### SDG:er kan anpassas på följande sätt SDG:er stöder följande alternativ: * Dedikerat anknytningsnummer * Tilldelat direktinringningsnummer * Tidszon * Kontorstider * Inspelade hälsningar * Gruppmedlemmar * Rutt till: * Användare * Interaktiv talsvarsmenu (IVR) * Gruppmedlemmar * Telefonnummer * Samtalsfördelning: * Samtidigt * Sekventiellt ### Hårdvaru- och nätverksöverväganden Denna avdelning diskuterar hårdvaru- och nätverksöverväganden för ZPLS-modulen, en SBC-integration, Zoom-klienter och telefonenheter. Efter att ha läst denna avdelning kan du förvänta dig att ha en förståelse för nödvändig nätverkskommunikation och konfigurationer för en ZPLS-distribution. {% hint style="info" %} Denna avdelning är dedikerad till hårdvarudistribution och nätverks *designöverväganden*. Se avsnittet om [distribuera ZPLS](#_wrba5u2ahyc) för steg-för-steg-distributionsinstruktioner. {% endhint %} #### Distribuering och nätverksöverväganden för ZPLS-modulen **ZPLS-modulen kräver en statisk IPv4-adress inom ditt nätverk** ZPLS-modulen bör distribueras i ett internt LAN med en statisk IPv4-adress som är åtkomlig för Zoom Phone-enheter och skrivbordsklienter. ZPLS-modulen stödjer för närvarande inte IPv6-adresser. **ZPLS-modulen måste upprätthålla periodiska HTTPS-anslutningar med Zoom Phone-molnet** ZPLS-modulen kräver periodiska HTTPS-anslutningar med Zoom Phone-molnet för att [synkronisera konto- och användarinställningar](#_54gf3fuxcnk5). I de flesta fall kan en ZPLS-modul distribueras på ett internt LAN inom en kunds nätverk. Alternativt kan ett DMZ-nätverk användas i vissa omständigheter; nätverksadministratörer måste dock säkerställa att kommunikation är möjlig genom företagsbrandväggen. I båda fallen krävs att administratörer justerar företagsbrandväggspolicyn för att möjliggöra kommunikation mellan ZPLS-modulen och Zoom Cloud. **ZPLS-modulen måste upprätthålla en regelbunden OPTIONS-ping med Zoom Phone-molnet** När den är i viloläge måste ZPLS-modulen upprätthålla en OPTIONS keepalive-ping med Zoom Phone-molnet för att övervaka anslutningen. Om både klientenheter och ZPLS-modulen inom en plats förlorar anslutning till Zoom Phone-molnet kommer stödda klienter och enheter att registrera sig till ZPLS-modulen med SIP Digest-autentisering över TLS v1.2. #### SBC-distribution och nätverksöverväganden **En SBC måste vara nåbar från ZPLS och Zoom-molnet när det är möjligt** Kunder bör säkerställa att SBC:n upprätthåller anslutning både med ZPLS-modulen och Zoom Phone-molnet när det är möjligt. Kunder kan tillhandahålla en dual-NIC SBC konfigurerad med en privat och en offentlig IPv4-adress, eller säkerställa att statiska 1:1 NAT-regler finns på edge-brandväggen utöver att öppna de erforderliga portarna. **En SBC måste upprätthålla TLS- och UDP-anslutning mellan Zoom Phone-molnet och ZPLS-modulen** Under rutinmässig drift måste en SBC upprätthålla TLS- och UDP-anslutning både till Zoom Phone-molnet och den associerade platsens ZPLS-modul. Denna anslutning används för att routa eventuella samtal till ett BYOC-listat telefonnummer [genom Zoom Phone-molnet](#_zgofkpkt74xr). OPTIONS keepalive-mekanismen är automatiskt aktiverad mellan ZPLS och SBC och är valfri mellan SBC och molnet. #### Överväganden för Zoom-klienter och telefonenheter **Klienter och enheter måste kunna upptäcka platsens ZPLS-modul inom det lokala nätverket** Klienter och stödda enheter [aktiverade för telefonöverlevnadsförmåga](#_ah8xua8wdq10) upptäcker den lämpliga failover-ZPLS-modulen från Zoom Phone-molnet under uppstart. Modulen måste dock redan vara [bunden till Phone System-platsen](#_k11n5zxkx1pq) med en internt upptäckbar IPv4-adress. **Enheter bör ha en statisk IP eller tilldelas en privat IP via en lokal DHCP-server** För att mildra potentiella problem bör telefonenheter tilldelas en statisk IP eller en intern IP via en lokal DHCP-server. Om en enhet inte tilldelas en statisk IP eller om en DHCP-server inte är tillgänglig under ett överlevnadsfall kan telefonenheter misslyckas med att registrera sig. **Klienter och enheter måste upprätthålla regelbunden en OPTIONS-ping med Zoom Phone-molnet** Liknande ZPLS-modulen måste stödda klienter och enheter upprätthålla en OPTIONS keepalive-ping till Zoom Phone-molnet för att avgöra datacentrets anslutningsstatus. Vid ett avbrott fortsätter klienten att skicka keepalive-meddelanden för att upptäcka när molntjänsten återkommer och initiera återupptagande av normal drift. Denna process är automatisk och kan inte inaktiveras. #### Brandväggs- och nätverksdatagflöde Se avsnittet om [Nätverksportar och dataflöde](#_pswiusfsww6t).