Überlegungen zur PSTN-Integration

Dieser Abschnitt gilt für Kunden, die erwägen, das ZPLS-Modul mit einem SBC und einer PSTN-Verbindung für zusätzliche Überlebensfähigkeit zu integrieren. Kunden, die nicht planen, das ZPLS-Modul mit PSTN-Konnektivität zu integrieren, können diesen Abschnitt ohne Konsequenzen überspringen.

Überlegungen zur SBC-Integration

SBC-Anforderungen

Um ein SBC zur Überlebensfähigkeit in Zoom zu integrieren, muss ein SBC die folgenden Anforderungen erfüllen:

• TLS 1.2 und SRTP

• Unterstützung für Mutual TLS

• Session Initiation Protocol (SIP)

• DTMF (RFC-2833)

• Topology Hiding (RFC-5853)

• SIP Early Offer (verpflichtend)

• Opus-, G.711 μ-law-, G.711 A-law- und G.729-Codecs

PSTN-Integrationen erfordern ein SBC und einen zuverlässigen Drittanbieter

Für PSTN-Konnektivität müssen Kunden einen Session Border Controller (SBC) bereitstellen, der entweder mit einer Legacy-Verbindung oder mit einem SIP-Trunk mit einer Mobilfunk- oder alternativen Verbindung (z. B. DSL) verbunden ist. Kunden sollten beachten, dass any an SBC bereitgestellte SIP-Trunks möglicherweise von demselben Internetdienst abhängig sind, der gerade einen Ausfall hat. Aufgrund dieser Möglichkeit sollten Kunden eine zuverlässige tertiäre Verbindung für die PSTN-Konnektivität in Betracht ziehen.

Jedes für Zoom Phone BYOC zertifizierte SBC kann verwendet werden

Jeder Session Border Controller (SBC), der für Zoom Phone zertifiziert ist, kann auch mit dem ZPLS-Modul verwendet werden. Kunden, die bereits einen Zoom Phone BYOC-Plan nutzen, benötigen kein zusätzliches oder separates SBC für Zwecke der Überlebensfähigkeit.

Die DigiCert-Zertifikate von Zoom müssen auf dem SBC installiert sein

Um TLS-Konnektivität sowohl zum ZPLS-Modul als auch zur Zoom-Cloud herzustellen, müssen die DigitCert-Root- und Zwischenzertifikate auf dem SBC installiert sein.

SBCs müssen eingehende Anrufe als erste und zweite Routing-Auswahl an Zoom Phone-Rechenzentren weiterleiten und das ZPLS-Modul als dritte

Kunden-SBCs müssen eingehende Anrufe aus dem PSTN zuerst an die primäre und sekundäre SIP-Zone weiterleiten, bevor sie das ZPLS-Modul versuchen. Mit dieser Konfiguration werden Anrufe nur während eines Überlebensereignisses zum ZPLS-Modul weitergeleitet, da das SBC und die Zoom Phone-Rechenzentren ansonsten eine stabile Konnektivität aufrechterhalten sollten.

Die Nichteinhaltung dieser Logik kann zu Ausfällen bei der Anrufzustellung führen, da das ZPLS-Modul Anrufe nicht an in der Cloud registrierte Geräte weiterleiten kann.

Sobald die Zoom Phone-Cloud nach einem Überlebensereignis wieder verfügbar ist, kann ein SBC vorübergehend versuchen, BYOC-Nummern an die Zoom-Cloud zu leiten, während das Client-Gerät der betroffenen Nummer beim ZPLS-Modul registriert ist. Sollte dies auftreten, folgt das Anrufrouting den Einstellungen für Wenn ein Anruf nicht beantwortet wird während dieses Übergangszeitraums.

Ausgehende Anrufe vom ZPLS-Modul müssen an das SBC und den PSTN-SIP-Trunk geleitet werden

Wenn der Überlebensmodus aktiv ist, müssen Anrufe vom ZPLS in das SBC an den PSTN-SIP-Trunk geleitet werden, um externe Telefonverbindungen herzustellen. Alle Anrufe an Nummern, die nicht beim ZPLS-Modul registriert sind, werden im E.164-Format an das für Überlebensfähigkeit konfigurierte SBC gesendet.

Überlegungen zur lokalen Überlebensfähigkeit bei Rufweiterleitung

Während eines Überlebensereignisses sind von Zoom Phone bereitgestellte Telefonnummern extern nicht erreichbar, sofern sie nicht über Rufweiterleitung umgeleitet werden

Während eines Überlebensereignisses sind aus Sicht der Cloud von Zoom bereitgestellte Telefonnummern extern nicht erreichbar. Folglich können Benutzer an betroffenen Standorten unerreichbar sein, sofern Anrufe an ihre Hauptnummern nicht an eine alternative Nummer weitergeleitet werden, die mit einem lokalen SBC verbunden ist.

Häufig betroffene Nummern können beispielsweise Nummern sein, die folgenden zugewiesen sind: Benutzer, gemeinsame Bereiche, automatische Telefonzentralen (AR), Shared Line Groups (SLG) und Call Queues (CQ).

Kunden, die ein vor Ort bereitgestelltes BYOC verwenden, benötigen keine erweiterten Konfigurationen und können die Rufweiterleitung umgehen, indem sie dem ZPLS-Modul von ihrem SBC eine tertiäre Route hinzufügen

Kunden, die einen vor Ort basierten BYOC-Plan verwenden (d. h. Kunden, die keine bei Zoom Phone registrierten Nummern verwenden), benötigen keine erweiterten Konfigurationen, um die Rufweiterleitung zu aktivieren. Stattdessen können BYOC-Kunden dem ZPLS-Modul eine tertiäre Route vom premises-basierten SBC hinzufügen.

Rufweiterleitungskonfigurationen werden von einem Administrator oder autorisierten Benutzer über das Webportal festgelegt

Ein Kontoadministrator oder autorisierter Benutzer kann die Logik der Rufweiterleitung konfigurieren über das Webportal durch manuelle Eingabe oder einen massenhaften CSV-Upload.

Benutzer, für die Rufweiterleitung konfiguriert ist, haben drei zugewiesene Nummern

Nach der Zuweisung einer BYOC-Nummer zu einem Benutzer für die Überlebensfähigkeit durch Rufweiterleitung wird dem Client-Gerät mindestens drei Nummern zugewiesen:

1. Eine interne Nebenstelle mit vorangestelltem Standortcode

2. Eine von Zoom bereitgestellte PSTN-Nummer

3. Eine BYOC-PSTN-Nummer

Telefonnummern können auf maximal eine BYOC-Nummer weitergeleitet werden

Jede Zoom Phone-Nummer kann auf maximal eine andere BYOC-Nummer weitergeleitet werden. Sie können jedoch mehrere Telefonnummern an dieselbe BYOC-Nummer weiterleiten.

Beispielsweise kann Johns zugewiesene Telefonnummer X55-555-5555 an die Betreiber-Nummer seines Gebäudes X99-999-9999 weitergeleitet werden. Ebenso können Johns Kollegen ihre Nummern (X55-555-5554, X55-555-5553 usw.) an X99-999-9999 weiterleiten lassen. Alternativ kann jeder Benutzer seine Telefonnummer an eine völlig eindeutige Nummer weiterleiten lassen, z. B. X55-555-5554 an X99-999-9998 und X55-555-5553 an X99-999-9997. Allerdings kann keine einzelne Person ihre Nummer sowohl an X99-999-9999 als auch an X99-999-9998 weiterleiten lassen.

Die Rufweiterleitung muss deaktiviert bleiben, bis ein Überlebensereignis eintritt

Obwohl ein Administrator die Logik der Rufweiterleitung für einen Standort im Voraus vorkonfigurieren kann, muss die Rufweiterleitungsfunktion bis zum Eintritt eines Überlebensereignisses deaktiviert bleiben. Wenn die Rufweiterleitung während des normalen Betriebs aktiviert ist, werden alle eingehenden Anrufe an eine bei Zoom Phone registrierte Nummer an das lokale SBC und die zugehörige BYOC-Telefonnummer weitergeleitet und umgehen damit die Zoom Phone-Dienste. Daher muss die Rufweiterleitung während des normalen Betriebs deaktiviert bleiben, um das reguläre Zoom Phone-Routing beizubehalten.

Die Rufweiterleitung kann nur von einem autorisierten Benutzer oder Administrator mit einer funktionierenden Internetverbindung aktiviert werden

Während eines Überlebensmodus-Ereignisses wird davon ausgegangen, dass die Internetverbindung eines Standorts nicht verfügbar ist. Da die Rufweiterleitung jedoch für den Standardbetrieb deaktiviert bleiben muss, kann sie nur von einem autorisierten Benutzer oder Administrator mit einer funktionierenden Internetverbindung wie einem Mobilfunkdatenplan oder einer alternativen Internetverbindung an einem anderen Standort aktiviert werden.

Um Ausfallzeiten zu minimieren und die Geschäftskontinuität sicherzustellen, empfiehlt Zoom Unternehmen, zuverlässige Verfahren zum Aktivieren der Rufweiterleitungslogik über das Webportal während eines Überlebensereignisses einzurichten.

Rufweiterleitungsregeln können für den gesamten Standort oder für einzelne Nummern gelten

Während eines Überlebensereignisses kann ein Administrator oder autorisierter Benutzer Rufweiterleitungsregeln für den gesamten Standort oder für bestimmte Nummern über das Webportal aktivieren.

Sobald die Rufweiterleitung für die Telefonnummer eines Benutzers aktiviert ist, klingelt Zoom das in der Cloud registrierte Client-Gerät des Benutzers nicht mehr, selbst wenn dieses eine unabhängige Cloud-Verbindung aufrechterhält

Wenn die Rufweiterleitung für eine bei Zoom Phone registrierte Nummer aktiviert ist, versucht Zoom nicht, Anrufe an den Benutzer über die Cloud zu leiten. Folglich werden alle Anrufe, selbst wenn ein betroffener Benutzer ein in der Cloud registriertes Gerät wie ein Mobiltelefon hat, sofern die Telefonnummer zur Rufweiterleitung markiert ist, über das PSTN an das SBC des Unternehmens geleitet.

Beispielsweise erlebt ein Standort ein Überlebensmodus-Ereignis und das Mobiltelefon eines Benutzers ist über die Datenverbindung seines Mobilfunkanbieters mit der Zoom Phone-Cloud verbunden. Wenn die Telefonnummer eines Benutzers zur Rufweiterleitung markiert ist, wird die Zoom Phone-Cloud nicht seine Zoom Phone-Nummer über die mobile App klingeln lassen, trotz der stabilen Verbindung. Stattdessen werden alle Anrufe weiterhin über das PSTN an das SBC des Kunden geleitet.

Wenn für einen Benutzer während eines Überlebensereignisses keine Rufweiterleitung aktiviert ist, folgen eingehende Anrufe den Anrufbearbeitungspräferenzen jedes Benutzers

Wenn während eines Überlebensereignisses keine Rufweiterleitung aktiviert ist, werden eingehende Anrufe gemäß der Anrufbearbeitungslogik für jeden einzelnen Benutzer behandelt. Wenn ein Benutzer keinen Backup-Telefonclient hat, der in der Cloud registriert ist, wie z. B. ein Mobiltelefon, unterliegen Anrufer den Regeln, die durch den Wenn ein Anruf nicht beantwortet wird Abschnitt der Anrufbearbeitungseinstellungen definiert sind.

Die Rufweiterleitung gilt nur für eingehende PSTN-Anrufe

Die Rufweiterleitung für Überlebensfähigkeit gilt nur für Anrufe, die über das PSTN und/oder die Zoom Phone-Cloud geroutet werden. Anrufe, die von bei Zoom registrierten Nebenstellen innerhalb desselben Standorts ausgehen, versuchen zuerst, eine Verbindung über das ZPLS-Modul herzustellen, und zweitens über das PSTN, sofern ein SBC verbunden ist. Anrufe, die keine Verbindung herstellen können, unterliegen ansonsten der Behandlung, die durch den Wenn ein Anruf nicht beantwortet wird Abschnitt der Call Handling-Regeln in den Telefoneinstellungen eines Benutzers festgelegt ist.

Ablauf der Rufweiterleitung

Das folgende Diagramm beschreibt die Logik der Rufweiterleitung (sobald aktiviert) während eines Überlebensereignisses. Diese Logik bleibt in Kraft, bis die Rufweiterleitung deaktiviert wird oder der Standardbetrieb wiederhergestellt ist. Wenn die Rufweiterleitung jedoch nach Wiederherstellung des Standardbetriebs weiterhin aktiviert bleibt, werden weitergeleitete Anrufe von der Zoom Phone-Cloud zum SBC und zurück zur Cloud „hairpinnen“, bevor sie an das Gerät eines Benutzers zugestellt werden. Aus diesem Grund sollte die Rufweiterleitung nach einem Überlebensereignis umgehend deaktiviert werden.

1. Ein externer Anrufer initiiert einen Anruf an eine bei Zoom Phone registrierte Nummer und wird über das PSTN geroutet.

2. Der Anruf wird an die Zoom Phone-Cloud weitergeleitet, und die gewählte Telefonnummer wird als von der Rufweiterleitung betroffen identifiziert.

Wenn die Rufweiterleitung nicht aktiviert ist, folgt Zoom Phone der Wenn ein Anruf nicht beantwortet wird Logik für diesen bestimmten Benutzer oder diese bestimmte Nebenstelle.

1. Da die Rufweiterleitung aktiviert ist, versucht Zoom nicht, den Benutzer zu alarmieren, und leitet stattdessen den Anruf zur festgelegten Rufweiterleitungsnummer über das PSTN weiter.

2. Der Anruf wird vom PSTN an das Überlebens-SBC weitergeleitet.

3. Das Überlebens-SBC leitet den Anruf an das ZPLS-Modul weiter.

4. Das ZPLS-Modul leitet den Anruf an die registrierten Client(s) des Benutzers weiter, sofern diese verbunden sind.

Überlegungen zur Emergency Location Identification Number (ELIN)

Eine ELIN ist eine standortspezifische Telefonnummer, die bei Wahl der Notrufdienste Standortinformationen an die Rettungsdienste übermittelt

Eine Emergency Location Identification Number (ELIN) ist eine dedizierte Telefonnummer, die von Public Safety Answering Points (PSAP) verwendet wird, um die physische Adresse eines Anrufers bei einem Notruf zu identifizieren. Für diese Funktion müssen Unternehmen mit ihrem PSTN-Diensteanbieter zusammenarbeiten, um eine Adresse einer Telefonnummer zuzuordnen, damit die Adresse in einer automatischen Standortidentifikation (ALI)-Datenbank erscheint, wenn der Anruf von einem PSAP-Mitarbeiter entgegengenommen wird.

Beispielsweise kann man sich einen Universitätscampus vorstellen, der sich über mehrere Gebäude erstreckt, wobei jedes Gebäude durch einen separaten Zoom Phone-Standort repräsentiert ist. Wenn ein Benutzer während eines Überlebensereignisses von einem Telefon oder Gerät aus den Notruf wählt das dem Standort zugeordnet ist, erhält der Notdienst automatisch die vollständige im Datensatz hinterlegte Adresse für den Standort, sofern der Standort beim Diensteanbieter konfiguriert und aktuell ist.

Jeder Standort kann mehrere ELINs unterstützen

Kunden können mehreren ELINs einem Standort zuweisen, um einen Pool an Notrufnummern bereitzustellen. Im Falle eines Notfalls während eines Überlebensereignisses ermöglicht dies, dass mehrere Anrufer jeweils eine eindeutig zugewiesene ELIN haben, wodurch Rettungsdienste den ursprünglichen Anrufer bei Rückruf leichter erreichen können.

Zusätzlich kann eine ELIN einem Benutzer oder einem Telefon in einem gemeinsamen Bereich zugewiesen werden, was eine feinere ELIN-Zuweisung als auf Standortebene ermöglicht und einen präziseren Standort für Rettungsdienste bietet.

Während eines Überlebensereignisses werden alle Notrufe durch die ELIN ersetzt

Wenn ein Benutzer während eines Überlebensereignisses einen Notruf tätigt, wird die Rufnummer des Anrufers, sofern eine verfügbar ist, durch die auf Standortebene festgelegte ELIN ersetzt. Dies ermöglicht es Benutzern, die keine direkte Nummer haben, den Notdienst anzurufen und für einen Rückruf durch den Notdienst erreichbar zu sein.

Eine ELIN-Nummer muss eine BYOC-Nummer sein, die mit dem PSTN-Trunk des Standorts SBC verknüpft ist

Die ELIN eines Standorts muss eine BYOC-Nummer sein, die auf einem PSTN-Trunk terminiert ist, der sich am Failover-SBC des Standorts befindet. Kein anderer Nummerntyp kann verwendet werden.

Das ZPLS-Modul leitet Notdienstrückrufe automatisch für bis zu 2 Stunden an die ursprüngliche Nebenstelle des Anrufers weiter

Wenn ein Notdienstmitarbeiter einen Rückruf an die ELIN tätigt, leitet das ZPLS-Modul den Anruf an den ursprünglichen Benutzer zurück, der den Notruf getätigt hat. Das ZPLS-Modul wird PSAP-Rückrufe an den ursprünglichen Anrufer bis zu 2 Stunden weiterleiten. Derzeit ist diese Funktionalität auf den ersten Anrufer beschränkt.

Sobald eine Telefonnummer als ELIN festgelegt ist, kann sie keinem Benutzer oder Gerät zugewiesen werden

Sobald ein Administrator eine BYOC-Nummer als designierte ELIN für einen Standort zugewiesen hat, kann diese BYOC-Nummer keinem Benutzer oder einer anderen Zoom Phone-Entität zugewiesen werden, es sei denn, sie wird freigegeben.

Kunden sind dafür verantwortlich, die mit ihren ELINs für jeden Standort verknüpften physischen Adressen zu pflegen und zu aktualisieren

Zoom übernimmt nicht die Verantwortung dafür, BYOC-Anbietern physische Adressen zu aktualisieren, die mit jeder ELIN korrelieren. Kunden sind dafür verantwortlich sicherzustellen, dass Notfalladressen korrekt der entsprechenden physischen Adresse zugeordnet sind.

Überlegungen zum PSTN-Routing

Wenn der Überlebensmodus aktiv ist, werden Medienpakete über das ZPLS-Modul geroutet

Wenn der Überlebensmodus aktiviert ist, kommunizieren Clients nicht direkt mit einem SBC oder anderen internen Clients; stattdessen werden Medienpakete über das ZPLS-Modul verankert oder „hairpinned“, ohne Unterstützung für Media-Offloading.

Das folgende Diagramm zeigt den Signalisierungs- und Medienpfad für aktive interne und externe Anrufe.

Anrufe werden nach Möglichkeit zuerst lokal zu routen versuchen

Wann immer möglich, versucht das ZPLS-Modul, Anrufe, die von registrierten Zoom-Clients ausgehen, an lokal registrierte Ziele zu routen. Anrufe werden nur an das SBC weitergeleitet, wenn das Ziel im Request-URI-Feld der eingehenden SIP-Invite-Nachricht nicht mit einer registrierten Nebenstelle übereinstimmt.

Eine registrierte Nebenstelle ist eine kurze Nebenstelle ohne Standortcode, eine lange Nebenstelle mit Standortcode, eine zugewiesene bei Zoom registrierte Nummer oder eine zugewiesene BYOC-Nummer. Administratoren sollten berücksichtigen, dass das ZPLS-Modul diese Daten einmal alle 10 Stunden.

Während eines Überlebensereignisses werden externe ausgehende Anrufe die BYOC-Nummer des Benutzers anzeigen

Während eines Überlebensereignisses enthalten externe ausgehende Anrufe von beim ZPLS registrierten Geräten die BYOC-Rufnummer des Anrufers. Das folgende Diagramm zeigt den Anrufablauf im Überlebensmodus für einen Benutzer:

Rückrufe können an die BYOC-Nummer eines Benutzers geleitet werden

Da externe ausgehende Anrufe, die während eines Überlebensereignisses getätigt werden, eine BYOC-Nummer verwenden, können externe Anrufer einen Rückruf an eine BYOC-Nummer statt an die bei Zoom registrierte Telefonnummer des Benutzers tätigen. Wenn das Überlebensereignis vorbei ist, werden Anrufe wieder über die Cloud geroutet wenn die korrekte Routing-Priorität konfiguriert ist. Wenn das Ereignis jedoch andauert, wird das SBC den Anruf an das ZPLS-Modul und das client-registrierte Gerät leiten.

Unterstützte Überlebens-Codecs

Unterstützte Überlebens-Codecs sind Opus, G.711 μ-law, G.711 A-law und G.729. Transkodierung oder Transrating von Audiocodecs wird nicht unterstützt. Alle an einem aktiven Anruf beteiligten Parteien müssen denselben Codec und dieselbe Abtastrate unterstützen.

Überlegungen zu Survivability Distribution Groups

Dieser Abschnitt behandelt Überlegungen zu Survivability Distribution Groups (SDGs). Kunden, die nicht planen, SDGs zu nutzen oder das ZPLS-Modul mit PSTN-Konnektivität zu integrieren, können diesen Abschnitt ohne Konsequenzen überspringen.

Survivability Distribution Groups bieten differenzierte Optionen für das Anrufrouting während eines Überlebensereignisses

Survivability Distribution Groups (SDGs) bieten Unternehmen differenzierte Optionen für das Anrufrouting – wie Call Queues und Interactive Voice Response (IVR)-Menüs – während eines Überlebensereignisses. Mit SDGs können Unternehmen weiterhin Kerntelefoniedienste und Anrufroutingkonfigurationen (ähnlich wie Call Queues, Auto Receptionists und Shared Line Groups) unterstützen, bis der Standardbetrieb wiederhergestellt ist.

SDGs sind nicht identisch mit Distribution Groups für den Normalbetrieb und müssen separat erstellt und verwaltet werden

Obwohl SDGs ähnliche Anrufrouting-Funktionalität wie Distribution Groups für den Normalbetrieb bieten, sind SDGs einzigartig und spezifisch für Überlebensereignisse und müssen folglich separat erstellt und verwaltet werden. Mit anderen Worten, SDGs nicht erben die Einstellungen oder Konfigurationen einer Distribution Group für den Normalbetrieb (z. B. Call Queue, Auto Receptionist, IVR usw.)

SDGs funktionieren am besten in Kombination mit einer BYOC‑PSTN-Integration und aktivierter Rufweiterleitung

Obwohl SDGs nur internen Support bieten können (d. h. Nicht-PSTN-Anrufe), eignen sie sich am besten in Kombination mit einer BYOC‑PSTN-Integration. Mit einer PSTN-fähigen SDG kann, sobald die Rufweiterleitung während eines Überlebensereignisses aktiviert ist, eine Hauptfirmennummer zur festgelegten SDG-Telefonnummer geleitet werden und der Anruf dem konfigurierten Routing-Profil folgen. Dies ermöglicht einem Unternehmen, externen Anrufern bis zur Wiederherstellung des Standardbetriebs ein konsistentes Anruffluss-Erlebnis zu bieten.

Das folgende Diagramm veranschaulicht die Routing-Logik für eine PSTN-fähige SDG:

SDGs können auf die folgenden Weisen angepasst werden

SDGs unterstützen die folgenden Optionen:

• Dedizierte Nebenstellennummer

• Zugewiesene Direct-Inward-Dial-Nummer

• Zeitzone

• Geschäftszeiten

• Aufgenommene Begrüßungen

• Gruppenmitglieder

• Weiterleiten an:

  • Benutzer

  • Interactive Voice Response (IVR)-Menü

  • Gruppenmitglieder

  • Telefonnummer

• Anrufverteilung:

  • Simultan

  • Sequenziell

Hardware- und Netzwerküberlegungen

Dieser Abschnitt behandelt Hardware- und Netzwerküberlegungen für das ZPLS-Modul, eine SBC-Integration, Zoom-Clients und Telefone. Nach dem Lesen dieses Abschnitts sollten Sie ein Verständnis der notwendigen Netzwerkkommunikation und -konfigurationen für eine ZPLS-Bereitstellung haben.

Dieser Abschnitt ist der Hardwarebereitstellung und dem Netzwerkdesign gewidmet Designüberlegungen. Verweisen Sie auf den Abschnitt zu Bereitstellung von ZPLS für schrittweise Bereitstellungsanweisungen.

Bereitstellungs- und Netzwerküberlegungen für das ZPLS-Modul

Das ZPLS-Modul erfordert eine statische IPv4-Adresse innerhalb Ihres Netzwerks

Das ZPLS-Modul sollte in einem internen LAN mit einer statischen IPv4-Adresse bereitgestellt werden, die für Zoom Phone-Geräte und Desktop-Clients zugänglich ist. Das ZPLS-Modul unterstützt derzeit keine IPv6-Adressen.

Das ZPLS-Modul muss periodische HTTPS-Verbindungen mit der Zoom Phone-Cloud aufrechterhalten

Das ZPLS-Modul benötigt regelmäßige HTTPS-Verbindungen zur Zoom Phone-Cloud, um Konto- und Benutzereinstellungen zu synchronisieren.

In den meisten Fällen kann ein ZPLS-Modul in einem internen LAN innerhalb des Netzwerks eines Kunden bereitgestellt werden. Alternativ kann in einigen Fällen ein DMZ-Netzwerk verwendet werden; Netzwerkadministratoren müssen jedoch sicherstellen, dass die Kommunikation durch die Unternehmensfirewall möglich ist. In beiden Fällen sind Administratoren verpflichtet, die Unternehmensfirewallrichtlinie anzupassen, um die Kommunikation zwischen dem ZPLS-Modul und der Zoom-Cloud zu ermöglichen.

Das ZPLS-Modul muss einen regelmäßigen OPTIONS-Ping mit der Zoom Phone-Cloud aufrechterhalten

Im Leerlaufzustand muss das ZPLS-Modul ein OPTIONS-Keepalive-Ping mit der Zoom Phone-Cloud aufrechterhalten, um die Konnektivität zu überwachen. Falls sowohl Client-Geräte als auch das ZPLS-Modul an einem Standort die Konnektivität zur Zoom Phone-Cloud verlieren, werden unterstützte Clients und Geräte beim ZPLS-Modul mit SIP-Digest-Authentifizierung über TLS v1.2 registriert.

Bereitstellungs- und Netzwerküberlegungen für SBCs

Ein SBC muss von ZPLS und der Zoom-Cloud aus erreichbar sein, wann immer möglich

Kunden sollten sicherstellen, dass das SBC nach Möglichkeit Konnektivität sowohl zum ZPLS-Modul als auch zur Zoom Phone-Cloud aufrechterhält. Kunden können ein duales NIC-SBC mit privater und öffentlicher IPv4-Adresse bereitstellen oder sicherstellen, dass statische 1:1-NAT-Regeln an der Edge-Firewall vorhanden sind und zusätzlich die erforderlichen Ports geöffnet werden.

Ein SBC muss TLS- und UDP-Konnektivität zwischen der Zoom Phone-Cloud und dem ZPLS-Modul aufrechterhalten

Während des normalen Betriebs muss ein SBC TLS- und UDP-Konnektivität sowohl zur Zoom Phone-Cloud als auch zum zugehörigen ZPLS-Modul des Standorts aufrechterhalten. Diese Verbindung wird verwendet, um potenzielle Anrufe an eine in BYOC gelistete Telefonnummer zu routen durch die Zoom Phone-Cloud. Der OPTIONS-Keepalive-Mechanismus wird automatisch zwischen ZPLS und dem SBC aktiviert und ist optional zwischen dem SBC und der Cloud.

Überlegungen zu Zoom-Clients und Telefongeräten

Clients und Geräte müssen in der Lage sein, das ZPLS-Modul des Standorts im lokalen Netzwerk zu entdecken

Clients und unterstützte Geräte für Telefon-Überlebensfähigkeit aktiviert entdecken das geeignete Failover-ZPLS-Modul aus der Zoom Phone-Cloud während des Bootvorgangs. Das Modul muss jedoch bereits an das Phone System Site gebunden sein mit einer intern entdeckbaren IPv4-Adresse.

Geräte sollten eine statische IP haben oder über einen lokalen DHCP-Server eine private IP zugewiesen bekommen

Um potenzielle Probleme zu mindern, sollten Telefone entweder eine statische IP erhalten oder über einen lokalen DHCP-Server eine interne IP zugewiesen bekommen. Wenn ein Gerät keine statische IP erhält oder während eines Überlebensereignisses kein DHCP-Server verfügbar ist, können sich Telefone nicht registrieren.

Clients und Geräte müssen regelmäßig einen OPTIONS-Ping mit der Zoom Phone-Cloud aufrechterhalten

Ähnlich wie das ZPLS-Modul müssen unterstützte Clients und Geräte ein OPTIONS-Keepalive-Ping zur Zoom Phone-Cloud senden, um den Konnektivitätsstatus des Rechenzentrums zu bestimmen. Im Falle eines Ausfalls sendet der Client weiterhin Keepalive-Nachrichten, um die Rückkehr des Cloud-Dienstes zu erkennen und die Wiederaufnahme des normalen Betriebs einzuleiten. Dieser Prozess ist automatisch und kann nicht deaktiviert werden.

Firewall- und Netzwerkdatenfluss

Siehe den Abschnitt zu Netzwerkports und Datenfluss.