Överväganden för PSTN-integreringar

Det här avsnittet gäller kunder som överväger att integrera ZPLS-modulen med en SBC- och PSTN-anslutning för ytterligare överlevnadsförmåga. Kunder som inte planerar att integrera ZPLS-modulen med PSTN-anslutning kan hoppa över det här avsnittet utan konsekvenser.

Överväganden för SBC-integrering

SBC-krav

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)

• Topologisk döljning (RFC-5853)

• SIP Early Offer (obligatoriskt)

• Opus, G.711 μ-law, G.711 A-law och G.729-codecs

PSTN-integreringar kräver en SBC och en tillförlitlig tredjepartsleverantör

För PSTN-anslutning måste kunder tillhandahålla en session border controller (SBC) som är ansluten till antingen en äldre anslutning eller en SIP-trunk med en mobil eller alternativ anslutning (t.ex. DSL). Kunder bör komma ihåg att alla SIP-trunkar som är driftsatta vid SBC:n kan vara beroende av samma internettjänst som har ett avbrott. På grund av denna möjlighet bör kunder överväga en tillförlitlig, tredje anslutning för PSTN-anslutning.

Alla Zoom Phone BYOC-certifierade SBC:er kan användas

Alla session border controllers (SBC) som är certifierade för Zoom Phone kan också användas med ZPLS-modulen. Kunder som redan har en Zoom Phone BYOC-plan behöver ingen ytterligare eller separat SBC för överlevnadsförmåga.

Zooms DigiCert-certifikat måste installeras på SBC:n

För att upprätta TLS-anslutning till både ZPLS-modulen och Zoom-moln måste Zooms DigitCerts rot- och mellanliggande certifikat installeras på SBC:n.

SBC:er måste dirigera inkommande samtal till Zoom Phone-datacenter som första och andra dirigeringsval, och ZPLS-modulen som tredje

Kundernas SBC:er måste dirigera inkommande samtal från PSTN till primär och sekundär SIP-zon innan de försöker använda ZPLS-modulen. Med denna konfiguration dirigeras samtal endast till ZPLS-modulen under en överlevnadshändelse, eftersom SBC:n och Zoom Phone-datacentren annars bör upprätthålla en stabil anslutning.

Underlåtenhet att följa denna logik kan leda till misslyckad samtalsleverans, eftersom ZPLS-modulen inte kan dirigera samtal till molnregistrerade enheter.

När Zoom Phone-molnet blir tillgängligt efter en överlevnadshändelse kan en SBC tillfälligt försöka dirigera BYOC-nummer till Zoom-molnet medan den berörda numrets klientenhet är registrerad på ZPLS-modulen. Om detta inträffar kommer samtalsdirigeringen att följa inställningarna för När ett samtal inte besvaras under denna övergångsperiod.

Utgående samtal från ZPLS-modulen måste dirigeras till SBC:n och PSTN-SIP-trunken

När överlevnadsläget är aktivt måste samtal från ZPLS till SBC:n dirigeras till PSTN-SIP-trunken för att upprätta externa telefonanslutningar. Alla samtal till nummer som inte är registrerade på ZPLS-modulen skickas till den SBC som är konfigurerad för överlevnadsförmåga i E.164-format.

Överväganden för lokal överlevnadsförmåga vid vidarekoppling

Under en överlevnadshändelse kommer telefonnummer som tillhandahålls av Zoom Phone inte att vara externt nåbara om de inte omdirigeras via vidarekoppling

Under en överlevnadshändelse kommer telefonnummer som tillhandahålls av Zoom inte att vara externt nåbara ur molnets perspektiv. Följaktligen kan användare som befinner sig på berörda platser vara otillgängliga om inte samtal till deras primära nummer vidarekopplas till ett alternativt nummer kopplat till en lokal SBC.

Vanliga exempel på påverkade nummer kan omfatta nummer tilldelade: användare, gemensamma utrymmen, Auto Receptions (AR), delade linjegrupper (SLG) och samtalsköer (CQ).

Kunder som använder ett lokalt baserat BYOC behöver inga avancerade konfigurationer och kan hoppa över vidarekoppling genom att lägga till en tredje 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) behöver inga avancerade konfigurationer för att aktivera vidarekoppling. I stället kan BYOC-kunder lägga till en tredje rutt till ZPLS-modulen från den platsbaserade SBC:n.

Vidarekopplingskonfigurationer ställs in av en administratör eller behörig användare från webbportalen

En kontoadmin eller behörig användare kan konfigurera logik för vidarekoppling från webbportalen via manuell inmatning eller en massuppladdning av CSV.

Användare som konfigurerats för vidarekoppling kommer att ha tre tilldelade nummer

Efter att ett BYOC-nummer har tillämpats på en användare för vidarekopplingsbaserad överlevnadsförmåga kommer klientenheten att tilldelas minst tre nummer:

1. Ett internt anknytningsnummer med platskod framför

2. Ett PSTN-nummer som tillhandahålls av Zoom

3. Ett BYOC-PSTN-nummer

Telefonnummer kan vidarekopplas till högst ett BYOC-nummer

Varje Zoom Phone-nummer kan vidarekopplas till högst ett annat BYOC-nummer. Du kan dock vidarekoppla flera telefonnummer till samma BYOC-nummer.

Till exempel, om John tilldelas telefonnumret X55-555-5555, kan Johns telefonnummer vidarekopplas till hans byggnads växelnummer på X99-999-9999. På samma sätt kan Johns kollegor också få sina nummer (X55-555-5554, X55-555-5553 osv.) vidarekopplade till X99-999-9999. Alternativt kan varje användare få sitt telefonnummer vidarekopplat till ett helt unikt nummer, till exempel att X55-555-5554 dirigeras till X99-999-9998 och X55-555-5553 dirigeras till X99-999-9997. Däremot kan ingen enskild användare få sitt nummer vidarekopplat till både X99-999-9999 och X99-999-9998.

Vidarekoppling måste förbli inaktiverad tills en överlevnadshändelse inträffar

Även om en administratör kan förkonfigurera logik för vidarekoppling för en plats i förväg, måste funktionen för vidarekoppling förbli inaktiverad tills en överlevnadshändelse inträffar. Om vidarekoppling är aktiverad under normal 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änsterna. För att upprätthålla vanlig Zoom Phone-dirigering måste därför vidarekoppling vara inaktiverad under normal drift.

Vidarekoppling av samtal kan endast aktiveras av en auktoriserad användare eller admin med en fungerande internetanslutning

Under ett evenemang i överlevnadsläge antas en plats internetanslutning vara otillgänglig. Men eftersom vidarekoppling av samtal måste förbli inaktiverad för standarddrift kan den endast aktiveras av en auktoriserad användare eller admin med en fungerande internetanslutning, till exempel ett mobildataabonnemang i en telefon, eller en alternativ internetanslutning på en annan plats.

För att minimera driftstopp och säkerställa affärskontinuitet rekommenderar Zoom att företag etablerar tillförlitliga procedurer för att aktivera logik för vidarekoppling av samtal från webbportalen under ett överlevnadshändelse-evenemang.

Regler för vidarekoppling av samtal kan tillämpas på hela platsen eller på enskilda nummer

Under ett överlevandevenemang kan en administratör eller auktoriserad användare aktivera regler för vidarekoppling av samtal för hela platsen eller för specifika nummer från webbportalen.

När vidarekoppling av samtal har aktiverats för en användares telefonnummer ringer Zoom inte en användares molnregistrerade klient, även om den upprätthåller en oberoende molnanslutning

När vidarekoppling av samtal är aktiverad för ett Zoom Phone-registrerat nummer försöker Zoom inte dirigera något samtal till användaren via molnet. Därför, även om en påverkad användare har en molnregistrerad enhet som en mobiltelefon, om telefonnumret är markerat för vidarekoppling av samtal, dirigeras alla samtal via PSTN till företagets SBC.

Till exempel upplever en plats ett evenemang i överlevnadsläge och en användares mobiltelefon är ansluten till Zoom Phone-molnet via operatörens dataanslutning. Om en användares telefonnummer är markerat för vidarekoppling av samtal, kommer Zoom Phone-molnet kommer inte att ringa deras Zoom Phone-nummer via mobilapp, trots den stabila anslutningen. I stället kommer alla samtal att fortsätta dirigeras via PSTN till kundens SBC.

Om vidarekoppling av samtal inte är aktiverad för en användare under ett överlevandevenemang kommer inkommande samtal att följa varje användares preferenser för samtalshantering

Om samtalsvidarekoppling inte är aktiverad under en överlevnadshändelse kommer inkommande samtal att hanteras enligt samtalshanteringslogiken för varje enskild användare. Om en användare inte har någon reservtelefonklient registrerad i molnet, till exempel en mobiltelefon, kommer uppringare att omfattas av reglerna som definieras av När ett samtal inte besvaras avsnittet för inställningar för samtalshantering.

Samtalsvidarekoppling gäller endast för inkommande PSTN-samtal

Samtalsvidarekoppling för överlevnad gäller endast för samtal som dirigeras via PSTN och/eller Zoom Phone-molnet. Samtal som kommer från Zoom-registrerade anknytningar inom samma plats försöker först ansluta via ZPLS-modulen och sedan via PSTN om en SBC är ansluten. Samtal som inte kan ansluta kommer annars att omfattas av behandlingen som definieras av När ett samtal inte besvaras avsnittet för regler för samtalshantering i en användares telefoninställningar.

Flöde för samtalsvidarekoppling

Följande diagram beskriver logiken för samtalsvidarekoppling (när den har aktiverats) under en överlevnadshändelse. Denna logik förblir i kraft tills samtalsvidarekoppling inaktiveras eller standarddriften återställs. Men om samtalsvidarekoppling förblir aktiverad efter när standarddriften har återställts kommer vidarekopplade samtal att hairpinna från Zoom Phone-molnet till SBC:n och tillbaka till molnet, innan de levereras till en användares enhet. Av denna anledning bör samtalsvidarekoppling inaktiveras omedelbart efter ett survivability-evenemang.

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 uppringda telefonnumret identifieras som påverkat av samtalsvidarekoppling.

Om samtalsvidarekoppling inte är aktiverad kommer Zoom Phone att följa När ett samtal inte besvaras logiken för den specifika användaren eller anknytningen.

1. Eftersom samtalsvidarekoppling är aktiverad kommer Zoom inte att försöka varna användaren utan i stället omdirigera samtalet till det angivna numret för samtalsvidarekoppling över PSTN.

2. Samtalet routas från PSTN till survivability-SBC:n.

3. Survivability-SBC:n vidarebefordrar samtalet till ZPLS-modulen.

4. ZPLS-modulen vidarebefordrar samtalet till användarens registrerade klient(er), om de är anslutna.

Överväganden för Emergency plats Identification Number (ELIN)

En ELIN är ett plats-exklusivt telefonnummer som vid uppringning kommunicerar platsinformation till räddningstjänsten

Ett nödlägesnummer för platsidentifiering (ELIN) är ett dedikerat telefonnummer som används av Public Safety Answering Points (PSAP) för att identifiera den fysiska adressen för en uppringare när denne ringer nödtjänster. För denna funktioner måste företag samarbeta med sin PSTN tjänsteleverantör för att koppla en adress till ett telefonnummer, för att bidra till att säkerställa att adressen finns listad i en databas för automatisk platsidentifiering (ALI) när samtal tas emot av en PSAP-operatör.

Till exempel, tänk dig 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ödtjänster under ett survivability-evenemang från en telefon eller en enhet associerad med platsen, räddningstjänsten kommer automatiskt att få hela adressen som finns på spela in för platsen, förutsatt att platsen är konfigurerad och uppdaterad hos tjänsteleverantören.

Varje plats kan Support flera ELIN:er

Kunder kan tilldela flera ELIN:er till en plats för en pool av resurser för nödnummer. Vid en nödsituation under ett överlevnadsevenemang kommer detta att tillåta flera uppringare att var och en ha ett unikt tilldelat ELIN, vilket kan hjälpa räddningstjänsten att nå den ursprungliga uppringaren om ett samtal returneras.

Dessutom kan en ELIN tilldelas en användare eller en telefon för gemensamt utrymme, vilket ger en mer detaljerad ELIN-tilldelning än på platsnivå och erbjuder en mer exakt plats för räddningstjänsten.

Under ett överlevnadsevenemang ersätts alla nödsamtal av ELIN

När en användare gör ett nödsamtal under ett survivability-evenemang kommer användarens nummer, om ett sådant är tillgängligt, att ersättas med det ELIN som har angetts på platsnivå. Detta gör det möjligt för användare som inte har ett direktnummer att ringa nödtjänster och vara nåbara för återuppringning från nödsamtalsoperatören.

Ett ELIN-nummer måste vara ett BYOC-nummer som är associerat med platsens SBC PSTN-trunk

En platsens ELIN måste vara ett BYOC-nummer som är terminerat på en PSTN-trunk som finns vid platsens failover-SBC. Ingen annan typ av nummer kan användas.

ZPLS-modulen kommer automatiskt att dirigera samtal från nödtjänstleverantörer till ELIN tillbaka till användarens anknytning som ursprungligen ringde, i upp till 2 timmar

Om en nödsamtalsoperatör ringer tillbaka till ELIN kommer ZPLS-modulen att dirigera samtalet tillbaka till den ursprungliga användaren som gjorde nödsamtalet. ZPLS-modulen kommer att fortsätta att dirigera PSAP-återuppringningar till den ursprungliga uppringaren i upp till 2 timmar. För närvarande är denna funktionalitet begränsad till den första uppringaren.

När ett telefonnummer har angetts som ELIN kan det inte tilldelas en användare eller enhet

När en administratör har tilldelat ett BYOC-nummer som det angivna ELIN för en plats, kan BYOC-numret inte tilldelas någon användare eller annan Zoom Phone-entitet om det inte är otilldelat.

Kunder ansvarar för att underhålla och uppdatera fysiska adresser som är kopplade till deras ELIN för varje plats

Zoom tar inte ansvar för att uppdatera BYOC-operatörer med fysiska adresser som motsvarar varje ELIN. Kunder ansvarar för att säkerställa att nödadresser är korrekt kopplade till rätt fysisk adress.

Överväganden för PSTN-dirigering

När överlevnadsläget är aktivt dirigeras mediepaket via ZPLS-modulen

När överlevnadsläget är aktiverat kommunicerar klienter inte direkt med en SBC eller andra interna klienter; i stället förankras mediepaket eller ”hairpinnas” via ZPLS-modulen, utan stöd för avlastning av media.

Följande diagram visar signalerings- och mediebanan för aktiva interna och externa samtal.

Samtal kommer först att försöka dirigeras lokalt

När det är möjligt kommer ZPLS-modulen att försöka dirigera samtal som kommer från registrerade Zoom-klienter till lokalt registrerade destinationer. Samtal vidarebefordras endast till SBC:n om destinationen i fältet Request URI i den inkommande SIP bjuda in inte matchar en registrerad anknytning.

En registrerad anknytning är en kort anknytning utan platskoden, en lång anknytning med platskoden, ett tilldelat Zoom-registrerat nummer eller ett tilldelat BYOC-nummer. Administratörer bör ha i åtanke att ZPLS-modulen uppdaterar dessa data en gång var 10:e timme.

Under en överlevnadshändelse kommer externa, utgående samtal att visa användarens BYOC-nummer

Under en överlevnadshändelse kommer externa, utgående samtal från ZPLS-registrerade enheter att innehålla BYOC-samtalsnumret. Följande diagram visar samtalsflödet i överlevnadsläge för en användare:

Returnerade samtal kan dirigeras till en användares BYOC-nummer

Eftersom externa, utgående samtal som placeras under en överlevnadshändelse kommer att använda ett BYOC-nummer, kan externa uppringare ringa tillbaka med ett BYOC-nummer i stället för en användares Zoom-registrerade telefonnummer. Om överlevnadshändelsen är över kommer samtal att dirigeras tillbaka via moln om rätt prioritet för dirigering är konfigurerad. Om händelsen däremot fortfarande pågår kommer SBC:n att dirigera samtal till ZPLS-modulen och den klientregistrerade enheten.

Kodekar som stöds för överlevnad

Kodekar som stöds för överlevnad är Opus, G.711 μ-law, G.711 A-law och G.729. Transkodning eller ändring av bithastighet för ljudkodekar stöds inte. Alla parter som deltar i ett aktiv samtal måste stödja samma kodek och samplingsfrekvens.

Överväganden för Survivability Distribution Groups

Det här avsnittet behandlar överväganden för Survivability Distribution Groups (SDG:er). Kunder som inte planerar att använda SDG:er eller integrera ZPLS-modulen med PSTN-anslutning kan hoppa över det här avsnittet utan konsekvenser.

Survivability Distribution Groups ger nyanserade alternativ för samtalsdirigering under en överlevnadshändelse

Survivability distribution groups (SDG:er) ger företag nyanserade alternativ för samtalsdirigering — som samtalsköer och interaktivt röstsvar (talsvar)-menyer — under en överlevnadshändelse. Med SDG:er kan företag fortsätta att stödja kärntjänster inom telefoni och konfigurationer för samtalsdirigering (liknande samtalsköer, automatiska receptionister och grupper med delad linje) tills standarddriften återställs.

SDG:er är inte samma sak som distributionsgrupper för standarddrift och måste byggas och underhållas separat

Även om SDG:er erbjuder liknande funktionalitet för samtalsdirigering som distributionsgrupper för standarddrift, är SDG:er unika och specifika för överlevnadshändelser och måste därför byggas och underhållas separat. Med andra ord, SDG:er kommer inte att ärver inställningar eller konfigurationer från en distributionsgrupp för standarddrift (dvs. samtalskö, automatisk receptionist, talsvar osv.)

SDG:er fungerar bäst tillsammans med en BYOC-PSTN-integrering och aktiverad vidarekoppling av samtal

Även om SDG:er kan ge endast internt stöd (dvs. icke-PSTN-samtal), fungerar de bäst tillsammans med en BYOC-PSTN-integrering. Med en PSTN-aktiverad SDG kan ett huvudsakligt företagsnummer, när vidarekoppling av samtal har aktiverats under en överlevnadshändelse, dirigeras till det angivna SDG-telefonnumret, och samtalet följer den konfigurerade dirigeringsprofilen. Detta gör det möjligt för ett Business att ge en konsekvent upplevelse av samtalsflödet för externa uppringare tills standarddriften återställs.

Följande diagram visar logiken för samtalsdirigering 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 direktnummer för inkommande samtal

• Tidszon

• kontorstider

• Inspelade hälsningar

• Gruppmedlemmar

• Dirigera till:

  • Användare

  • interaktivt röstsvar (talsvar)-meny

  • Gruppmedlemmar

  • Telefonnummer

• Samtalsfördelning:

  • samtidig

  • sekventiell

Överväganden för hårdvara och nätverk

Det här avsnittet behandlar överväganden för hårdvara och nätverk för ZPLS-modulen, en SBC-integrering, Zoom-klienter och telefonienheter. Efter att ha läst det här avsnittet 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.

Det här avsnittet är avsett för distribution av hårdvara och nätverk designöverväganden. Se avsnittet om att distribuera ZPLS för steg-för-steg-instruktioner för distribution.

Överväganden för distribution och nätverk för ZPLS-modulen

ZPLS-modulen kräver en statisk IPv4-adress inom ditt nätverk

ZPLS-modulen bör distribueras på ett internt LAN med en statisk IPv4-adress som är tillgänglig för Zoom Phone-enheter och skrivbordsklienter. ZPLS-modulen stöder inte IPv6-adresser för närvarande.

ZPLS-modulen måste upprätthålla periodiska HTTPS-anslutningar med Zoom Phone-moln

ZPLS-modulen kräver periodiska HTTPS-anslutningar med Zoom Phone-moln för att synkronisera konto- och användarinställningar.

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 fall; nätverksadministratörer måste dock säkerställa att kommunikation är möjlig genom Enterprise-brandväggen. I båda fallen måste administratörer justera företagets brandväggspolicy för att aktivera kommunikation mellan ZPLS-modulen och Zoom-moln.

ZPLS-modulen måste upprätthålla en regelbunden OPTIONS-ping med Zoom Phone-moln

När ZPLS-modulen är i viloläge måste den upprätthålla en OPTIONS keepalive-ping med Zoom Phone-moln för att övervaka anslutningen. Om både klientenheter och ZPLS-modulen inom en plats förlorar anslutningen till Zoom Phone-moln kommer klienter och enheter som stöds att registrera sig till ZPLS-modulen med SIP Digest-autentisering över TLS v1.2.

Överväganden för SBC-distribution och nätverk

En SBC måste vara nåbar från ZPLS och Zoom-moln när det är möjligt

Kunder bör säkerställa att SBC:n upprätthåller anslutning till både ZPLS-modulen och Zoom Phone-moln, när det är möjligt. Kunder kan provisionera en SBC med dubbla NIC:ar konfigurerad med en privat och offentlig IPv4-adress, eller säkerställa att statiska 1:1 NAT-regler finns på kantbrandväggen utöver att de nödvändiga portarna öppnas.

En SBC måste upprätthålla TLS- och UDP-anslutning mellan Zoom Phone-moln och ZPLS-modulen

Under rutinmässig drift måste en SBC upprätthålla TLS- och UDP-anslutning till både Zoom Phone-moln och den tillhörande platsens ZPLS-modul. Denna anslutning används för att dirigera eventuella samtal till ett BYOC-listat telefonnummer genom Zoom Phone-moln. OPTIONS keepalive-mekanismen aktiveras automatiskt mellan ZPLS och SBC:n och är valfri mellan SBC:n och moln.

Ö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 enheter som stöds aktiverade för telefonöverlevnad upptäcker den lämpliga failover-ZPLS-modulen från Zoom Phone-moln under uppstartsprocessen. Modulen måste dock redan vara bunden till telefonsystem-platsen 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 minska potentiella problem bör telefonenheter tilldelas en statisk eller 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 en överlevnadshändelse, kan telefonenheter misslyckas med att registrera sig.

Klienter och enheter måste upprätthålla en regelbunden OPTIONS-ping med Zoom Phone-moln

I likhet med ZPLS-modulen måste klienter och enheter som stöds upprätthålla en OPTIONS keepalive-ping till Zoom Phone-moln för att fastställa anslutningsstatus för datacentral. 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ägg och nätverkets dataflöde

Se avsnittet om Nätverksportar och dataflöde.