Überlegungen zur PSTN Integration

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

Überlegungen zur SBC-Integration

SBC-Anforderungen

Um einen SBC mit Zoom für die Ausfallsicherheit zu integrieren, muss ein SBC die folgenden Anforderungen erfüllen:

• TLS 1.2 und SRTP

• Support für Mutual TLS

• Protokoll zur Sitzung Initiierung (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 einen SBC und einen zuverlässigen Drittanbieter

Für PSTN-Konnektivität müssen Kunden einen Sitzungsgrenz-Controller (SBC) bereitstellen, der mit entweder einer Legacy-Verbindung oder einem SIP-Trunk mit einer Mobilfunk- oder alternativen Verbindung (z. B. DSL) verbunden ist. Kunden sollten bedenken, dass alle am SBC bereitgestellten SIP-Trunks von demselben Internetdienst abhängen können, der derzeit eine Störung erfährt. Aufgrund dieser Möglichkeit sollten Kunden für PSTN-Konnektivität eine zuverlässige, tertiäre Verbindung in Betracht ziehen.

Jeder SBC mit Zoom Phone-BYOC-Zertifizierung kann verwendet werden

Jeder Sitzungs-Border-Controller (SBC), der für Zoom Phone zertifiziert kann auch mit dem ZPLS-Modul verwendet werden. Kunden mit einem bestehenden Zoom Phone BYOC-Plan benötigen für die Ausfallsicherheit keinen zusätzlichen oder separaten SBC.

Zooms DigiCert-Zertifikate müssen auf dem SBC installiert werden

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

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

Kunden-SBCs müssen eingehende Anrufe aus dem PSTN an die primäre und sekundäre SIP-Zone weiterleiten, bevor das ZPLS-Modul versucht wird. Mit dieser Konfiguration werden Anrufe nur während eines Ausfalls-Events an das ZPLS-Modul weitergeleitet, da die SBCs und Zoom Phone-Rechenzentren andernfalls eine stabile Konnektivität aufrechterhalten sollten.

Wenn dieser Logik nicht gefolgt wird, kann dies zu Fehlern bei der Anrufzustellung führen, da das ZPLS-Modul keine Anrufe an Cloud-registrierte Geräte weiterleiten kann.

Sobald die Zoom Phone Cloud nach einem Survivability-Event verfügbar ist, kann ein SBC vorübergehend versuchen, BYOC-Nummern an die Zoom Cloud weiterzuleiten, während das Client-Gerät der betroffenen Nummer beim ZPLS-Modul registriert ist. Sollte dies eintreten, folgt die Anrufweiterleitung den Einstellungen für Wenn ein Anruf nicht beantwortet wird während dieses Zwischenzeitraums.

Ausgehend vom ZPLS-Modul müssen Anrufe an den SBC und den PSTN SIP-Trunk weitergeleitet werden

Wenn der Survivability-Modus aktiv ist, müssen Anrufe von ZPLS an den SBC an den PSTN SIP-Trunk weitergeleitet werden, um externe Telefonverbindungen herzustellen. Alle Anrufe an Nummern, die nicht beim ZPLS-Modul registriert sind, werden im E.164-Format an den für Survivability konfigurierten SBC gesendet.

Anrufweiterleitung: Überlegungen zur lokalen Survivability

Während eines Survivability-Events sind die von Zoom Phone bereitgestellten Telefonnummern extern nicht erreichbar, sofern sie nicht über Anrufweiterleitung weitergeleitet werden

Während eines Survivability-Events sind die von Zoom bereitgestellten Telefonnummern aus Sicht der Cloud extern nicht erreichbar. Daher können Benutzer an den betroffenen Standorten nicht erreichbar sein, sofern Anrufe an ihre primären Nummern nicht an eine alternative Nummer weitergeleitet werden, die mit einem lokalen SBC verknüpft ist.

Gängige Beispiele betroffener Nummern können Nummern umfassen, die folgenden zugewiesen sind: Benutzer, Gemeinsame Bereiche, Auto-Rezeptionen (AR), Gruppen mit gemeinsamer Leitung (SLG) und Anrufwarteschlangen (CQ).

Kunden, die ein on-premises-basiertes BYOC verwenden, benötigen keine erweiterten Konfigurationen und können die Anrufweiterleitung umgehen, indem sie ihrem ZPLS-Modul von ihrem SBC aus eine tertiäre Route hinzufügen

Kunden, die einen auf einer lokalen Umgebung basierenden BYOC-Plan verwenden (d. h. Kunden, die keine Zoom Phone-registrierten Nummern verwenden), benötigen keine erweiterten Konfigurationen, um die Anrufweiterleitung zu Aktivieren. Stattdessen können BYOC-Kunden dem ZPLS-Modul vom SBC vor Ort durch das Hinzufügen einer tertiären Route eine Route hinzufügen.

Die Konfigurationen für die Anrufweiterleitung werden von einem Administrator oder autorisierten Benutzer über das Webportal festgelegt

Ein Kontoadministrator oder autorisierter Benutzer kann die Logik für die Anrufweiterleitung Konfigurieren über das Webportal durch manuelle Eingabe oder einen CSV-Massen-Upload.

Benutzer, die für die Anrufweiterleitung konfiguriert wurden, haben drei zugewiesene Nummern

Nachdem einem Benutzer für die Überlebensfähigkeit der Anrufweiterleitung eine BYOC-Nummer zugewiesen wurde, wird dem Client-Gerät mindestens drei Nummern:

1. Eine interne Durchwahl mit vorangestelltem Standortcode

2. Eine von Zoom bereitgestellte PSTN-Nummer

3. Eine BYOC-PSTN-Nummer

Telefonnummern können an höchstens eine BYOC-Nummer weitergeleitet werden

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

Zum Beispiel kann, wenn John die Telefonnummer X55-555-5555 zugewiesen ist, Johns Telefonnummer an die Operatornummer seines Gebäudes unter X99-999-9999 weitergeleitet werden. Ebenso können auch die Telefonnummern seiner Kollegen (X55-555-5554, X55-555-5553 usw.) an X99-999-9999 weitergeleitet werden. Alternativ kann jeder Benutzer seine Telefonnummer an eine völlig eindeutige Nummer weiterleiten, z. B. X55-555-5554: Weiterleitung zu X99-999-9998 und X55-555-5553: Weiterleitung zu X99-999-9997. Allerdings kann für keinen einzelnen Benutzer seine Nummer sowohl an X99-999-9999 als auch an X99-999-9998 weitergeleitet werden.

Die Anrufweiterleitung muss deaktiviert bleiben, bis ein Survivability-Event auftritt

Obwohl ein Administrator die Logik der Anrufweiterleitung für einen Standort im Voraus bereitstellen kann, muss die Funktionalität der Anrufweiterleitung deaktiviert bleiben, bis ein Survivability-Event auftritt. Wenn die Anrufweiterleitung während des normalen Betriebs aktiviert ist, werden alle eingehenden Anrufe an eine bei Zoom Phone registrierte Nummer an den lokalen SBC und die zugehörige BYOC-Telefonnummer umgeleitet und umgehen dabei die Zoom Phone-Dienste. Daher muss die Anrufweiterleitung während des normalen Betriebs deaktiviert bleiben, um die reguläre Zoom Phone-Weiterleitung beizubehalten.

Das Aktivieren der Anrufweiterleitung ist nur durch einen autorisierten Benutzer oder Administrator mit einer funktionierenden Internetverbindung möglich

Während eines Survivability-Mode-Events wird davon ausgegangen, dass die Internetverbindung eines Standorts nicht verfügbar ist. Da die Anrufweiterleitung jedoch für den Standardbetrieb deaktiviert bleiben muss, ist das Aktivieren nur durch einen autorisierten Benutzer oder Administrator mit einer funktionierenden Internetverbindung wie einem Telefon-Datentarif oder einer alternativen Internetverbindung an einem anderen Standort möglich.

Um Ausfallzeiten zu minimieren und die Business-Kontinuität sicherzustellen, empfiehlt Zoom Unternehmen, zuverlässige Verfahren zum Aktivieren der Anrufweiterleitungslogik über das Webportal während eines Survivability-Events einzurichten.

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

Während eines Survivability-Events kann ein Administrator oder autorisierter Benutzer über das Webportal das Aktivieren von Anrufweiterleitungsregeln für den gesamten Standort oder für bestimmte Nummern vornehmen.

Sobald die Anrufweiterleitung für die Telefonnummer eines Benutzers aktiviert ist, wird Zoom den Cloud-registrierten Client eines Benutzers nicht klingeln lassen, selbst wenn er eine unabhängige Cloud-Verbindung aufrechterhält

Wenn die Anrufweiterleitung für eine bei Zoom Phone registrierte Nummer aktiviert ist, versucht Zoom nicht, einen Anruf an den Benutzer über die Cloud weiterzuleiten. Folglich werden, selbst wenn ein betroffener Benutzer ein Cloud-registriertes Gerät wie ein Mobiltelefon hat, alle Anrufe, sofern die Telefonnummer für die Anrufweiterleitung markiert ist, über das PSTN zum SBC des Unternehmens geleitet.

Zum Beispiel erlebt ein Standort ein Survivability-Mode-Event, und das Mobiltelefon eines Benutzers ist über die Datenverbindung seines Mobilfunkanbieters mit der Zoom Phone Cloud verbunden. Wenn die Telefonnummer eines Benutzers für die Anrufweiterleitung markiert ist, wird die Zoom Phone Cloud werden nicht ihre Zoom Phone-Nummer trotz der stabilen Verbindung über die mobile App klingeln lassen. Stattdessen werden alle Anrufe weiterhin über das PSTN zum SBC des Kunden geleitet.

Wenn für einen Benutzer während eines Survivability-Events die Anrufweiterleitung nicht aktiviert ist, folgen eingehende Anrufe den Anrufbearbeitungspräferenzen jedes Benutzers

Wenn die Anrufweiterleitung während eines Survivability-Events nicht aktiviert ist, werden eingehende Anrufe gemäß der Anrufbearbeitungslogik für jeden einzelnen Benutzer. Wenn ein Benutzer keinen am Cloud registrierten Backup-Telefonclient hat, wie z. B. ein Mobiltelefon, unterliegen Anrufer den Regeln, die im Wenn ein Anruf nicht beantwortet wird Abschnitt der Anrufbearbeitungseinstellungen.

Die Anrufweiterleitung gilt nur für eingehende PSTN-Anrufe

Die Anrufweiterleitung für Survivability gilt nur für Anrufe, die über das PSTN und/oder die Zoom Phone Cloud geroutet werden. Von Zoom-registrierten Nebenstellen innerhalb desselben Standorts ausgehende Anrufe versuchen zunächst, über das ZPLS-Modul zu verbinden, und anschließend über das PSTN, wenn ein SBC verbunden ist. Anrufe, die keine Verbindung herstellen können, unterliegen andernfalls der Behandlung, die im Wenn ein Anruf nicht beantwortet wird Abschnitt der Anrufbearbeitungsregeln in den Telefoneinstellungen eines Benutzers.

Anrufweiterleitungsablauf

Das folgende Diagramm beschreibt die Logik für die Anrufweiterleitung (sobald sie aktiviert ist) während eines Survivability-Events. Diese Logik bleibt wirksam, bis die Anrufweiterleitung deaktiviert wird oder der Standardbetrieb wiederhergestellt ist. Wenn die Anrufweiterleitung jedoch aktiviert bleibt nach Nachdem der Standardbetrieb wiederhergestellt ist, werden weitergeleitete Anrufe von der Zoom Phone Cloud zum SBC und zurück zur Cloud geleitet, bevor sie an das Gerät eines Benutzers zugestellt werden. Aus diesem Grund sollte die Anrufweiterleitung unverzüglich nach einem Survivability-Event 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 zur Zoom Phone Cloud geleitet, und die gewählte Telefonnummer wird als von der Anrufweiterleitung betroffen identifiziert.

Wenn die Anrufweiterleitung nicht aktiviert ist, folgt Zoom Phone der Wenn ein Anruf nicht beantwortet wird Logik für den jeweiligen Benutzer oder die jeweilige Nebenstelle.

1. Da die Anrufweiterleitung aktiviert ist, versucht Zoom nicht, den Benutzer mit einem Warnhinweis zu benachrichtigen, sondern leitet den Anruf stattdessen über das PSTN an die festgelegte Nummer für die Anrufweiterleitung weiter.

2. Der Anruf wird vom PSTN zum Survivability-SBC geroutet.

3. Der Survivability-SBC leitet den Anruf an das ZPLS-Modul weiter.

4. Das ZPLS-Modul leitet den Anruf an die registrierten Clients des Benutzers weiter, sofern verbunden.

Überlegungen zur Notfall-Standortidentifikationsnummer (ELIN)

Eine ELIN ist eine Standort-exklusive Telefonnummer, die Standortinformationen an Notdienste übermittelt, wenn sie gewählt wird

Eine Notfall-Standortidentifikationsnummer (ELIN) ist eine dedizierte Telefonnummer, die von Notrufzentralen (Notrufzentrale) verwendet wird, um die physische Adresse eines Anrufers bei einem Anruf bei Notdiensten zu identifizieren. Für diese Funktion müssen Unternehmen mit ihrem PSTN-Dienstanbieter zusammenarbeiten, um eine Adresse einer Telefonnummer zuzuordnen und dazu beizutragen, sicherzustellen, dass die Adresse in einer Datenbank für die automatische Standortidentifizierung (ALI) aufgeführt ist, wenn der Anruf von einem Mitarbeiter einer Notrufzentrale entgegengenommen wird.

Betrachten Sie beispielsweise einen Universitätscampus, der sich über mehrere Gebäude erstreckt, wobei jedes Gebäude durch einen separaten Zoom Phone-Standort dargestellt wird. Wenn ein Benutzer während eines Survivability-Events von einem Telefon oder Gerät aus Notdienste anruft das dem Standort zugeordnet ist, erhalten die Notdienste automatisch die vollständige Adresse, die für den Standort aufzeichnen hinterlegt ist, sofern der Standort konfiguriert und beim Dienstanbieter aktuell ist.

Jeder Standort kann mehrere ELINs unterstützen

Kunden haben die Möglichkeit zum Zuweisen mehrerer ELINs zu einem Standort für einen Pool von Notrufnummernressourcen. Im Fall eines Notfalls während eines Survivability-Events ermöglicht dies, dass mehreren Anrufern jeweils eine eindeutige ELIN zugewiesen wird, wodurch Notdienste den ursprünglichen Anrufer erreichen können, wenn sie einen Anruf zurückgeben.

Zusätzlich ermöglicht das Zuweisen einer ELIN an einen Benutzer oder ein Telefon im gemeinsamen Bereich eine granularere ELIN-Zuweisung als auf Standortebene und bietet Notdiensten einen präziseren Standort.

Während eines Survivability-Events werden alle Notrufe durch die ELIN ersetzt

Wenn ein Benutzer während eines Survivability-Events einen Notruf tätigt, wird die Rufnummer des Benutzers, falls eine verfügbar ist, durch die ELIN ersetzt, die auf Standortebene zugewiesen ist. Dadurch können Benutzer, die keine Direktnummer haben, die Notrufdienste anrufen und für einen Rückruf durch den Notrufoperator erreichbar sein.

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

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

Das ZPLS-Modul leitet Notrufanbieter-Anrufe an die ELIN automatisch für bis zu 2 Stunden zurück an die Durchwahl des Benutzers weiter, der ursprünglich gewählt hat

Wenn ein Notrufoperator einen Anruf an die ELIN zurückruft, leitet das ZPLS-Modul den Anruf an den ursprünglichen Benutzer zurück, der den Notruf getätigt hat. Das ZPLS-Modul leitet Rückrufe der Notrufzentrale weiterhin für bis zu 2 Stunden an den ursprünglichen Anrufer weiter. Derzeit ist diese Funktionalität auf den ersten Anrufer beschränkt.

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

Sobald ein Administrator eine BYOC-Nummer als zugewiesene ELIN für einen Standort zugewiesen hat, kann die 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 ihrer ELIN für jeden Standort verknüpften physischen Adressen zu pflegen und zu aktualisieren

Zoom übernimmt keine Verantwortung dafür, BYOC-Carrier mit physischen Adressen zu aktualisieren, die jeder ELIN entsprechen. Kunden sind dafür verantwortlich, sicherzustellen, dass Notrufadressen korrekt der entsprechenden physischen Adresse zugeordnet werden.

Überlegungen zur PSTN-Weiterleitung

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

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 Medien-Offloading.

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

Anrufe versuchen zunächst, lokal weitergeleitet zu werden

Wann immer möglich, versucht das ZPLS-Modul, Anrufe von registrierten Zoom-Clients an lokal registrierte Ziele weiterzuleiten. Anrufe werden nur dann an den SBC weitergeleitet, wenn das im Request-URI-Feld der eingehenden SIP-Einladen enthaltene Ziel nicht mit einer registrierten Durchwahl übereinstimmt.

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

Während eines Überlebens-Events zeigen externe, ausgehende Anrufe die BYOC-Nummer des Benutzers an

Während eines Überlebens-Events enthalten externe, ausgehende Anrufe von bei ZPLS registrierten Geräten die BYOC-Anrufernummer. Das folgende Diagramm zeigt den Anruffluss im Überlebensmodus für einen Benutzer:

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

Da externe, ausgehende Anrufe während eines Überlebens-Events eine BYOC-Nummer verwenden, können externe Anrufer einen Anruf über eine BYOC-Nummer statt über die bei Zoom registrierte Telefonnummer eines Benutzers zurückrufen. Wenn das Überlebens-Event beendet ist, werden Anrufe über die Cloud zurückgeleitet wenn die korrekte Weiterleitungspriorität konfiguriert ist. Wenn das Event jedoch noch andauert, leitet der SBC den Anruf an das ZPLS-Modul und das beim Client registrierte Gerät weiter.

Unterstützte Überlebens-Codecs

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

Überlegungen zu Überlebens-Verteilungsgruppen

In diesem Abschnitt werden Überlegungen zu Überlebens-Verteilungsgruppen (SDGs) erläutert. Kunden, die SDGs weder nutzen noch das ZPLS-Modul mit PSTN-Konnektivität integrieren möchten, können diesen Abschnitt folgenlos überspringen.

Überlebens-Verteilungsgruppen bieten während eines Überlebens-Events differenzierte Optionen zur Anrufweiterleitung

Überlebens-Verteilungsgruppen (SDGs) bieten Unternehmen während eines Überlebens-Events differenzierte Optionen zur Anrufweiterleitung – beispielsweise Warteschleifen und Sprachdialogsystem-Menüs (Sprachdialogsystem). Mit SDGs können Unternehmen weiterhin zentrale Telefonie-Dienste und Anrufweiterleitungs-Konfigurationen (ähnlich wie Warteschleifen, automatische Rufannahmen und Gruppen für gemeinsame Leitungen) unterstützen, bis der Standardbetrieb wiederhergestellt ist.

SDGs sind nicht dasselbe wie Verteilungsgruppen im Standardbetrieb und müssen separat erstellt und gepflegt werden

Obwohl SDGs ähnliche Funktionen zur Anrufweiterleitung wie Verteilungsgruppen im Standardbetrieb bieten, sind SDGs einzigartig und speziell auf Überlebens-Events ausgerichtet und müssen daher separat erstellt und gepflegt werden. Mit anderen Worten: SDGs werden nicht übernehmen die Einstellungen oder Konfigurationen einer Verteilungsgruppe im Standardbetrieb (d. h. Warteschleife, automatische Rufannahme, Sprachdialogsystem usw.)

SDGs lassen sich am besten mit einer BYOC-PSTN-Integration und aktivierter Anrufweiterleitung kombinieren

Obwohl SDGs ausschließlich interne Unterstützung bieten können (d. h. Nicht-PSTN-Anrufe), lassen sie sich am besten mit einer BYOC-PSTN-Integration kombinieren. Bei einer PSTN-fähigen SDG kann nach der Aktivierung der Anrufweiterleitung während eines Überlebens-Events eine Hauptfirmennummer an die vorgesehene SDG-Telefonnummer weitergeleitet werden, und der Anruf folgt dem konfigurierten Weiterleitungsprofil. Dadurch kann ein Business externen Anrufern ein einheitliches Anrufflusserlebnis bieten, bis der Standardbetrieb wiederhergestellt ist.

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

SDGs können auf folgende Weise angepasst werden

SDGs unterstützen die folgenden Optionen:

• Dedizierte Durchwahl

• Zugewiesene Direktdurchwahlnummer

• Zeitzone

• Geschäftszeiten

• Aufgezeichnete Begrüßungen

• Gruppenmitglieder

• Weiterleiten an:

  • Benutzer

  • Sprachdialogsystem-Menü (Sprachdialogsystem)

  • Gruppenmitglieder

  • Telefonnummer

• Anrufverteilung:

  • Simultan

  • Sequenziell

Überlegungen zu Hardware und Netzwerken

In diesem Abschnitt werden Überlegungen zu Hardware und Netzwerken für das ZPLS-Modul, eine SBC-Integration, Zoom-Clients und Telefongeräte erläutert. Nach dem Lesen dieses Abschnitts werden Sie die erforderliche Netzwerkkommunikation und Konfigurationen für eine ZPLS-Bereitstellung verstehen.

Dieser Abschnitt ist der Bereitstellung von Hardware und dem Netzwerk gewidmet Designüberlegungen. Siehe den Abschnitt über die Bereitstellung von ZPLS für schrittweise Bereitstellungsanweisungen.

Überlegungen zur Bereitstellung und Vernetzung des ZPLS-Moduls

Das ZPLS-Modul benötigt eine statische IPv4-Adresse in Ihrem Netzwerk

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 regelmäßige HTTPS-Verbindungen mit der Zoom Phone Cloud aufrechterhalten

Das ZPLS-Modul benötigt regelmäßige HTTPS-Verbindungen mit der Zoom Phone Cloud, um Konto- und Benutzereinstellungen 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 Enterprise-Firewall möglich ist. In beiden Fällen müssen Administratoren die Unternehmens-Firewallrichtlinie anpassen, um die Kommunikation zwischen dem ZPLS-Modul und der Zoom Cloud zu aktivieren.

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

Im Leerlauf muss das ZPLS-Modul einen 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 Verbindung zur Zoom Phone Cloud verlieren, registrieren sich unterstützte Clients und Geräte beim ZPLS-Modul mithilfe der SIP-Digest-Authentifizierung über TLS v1.2.

Überlegungen zur SBC-Bereitstellung und zum Netzwerk

Ein SBC muss nach Möglichkeit von ZPLS und Zoom Cloud aus erreichbar sein

Kunden sollten sicherstellen, dass der SBC nach Möglichkeit sowohl mit dem ZPLS-Modul als auch mit der Zoom Phone Cloud verbunden bleibt. Kunden können einen SBC mit zwei NICs bereitstellen, der mit einer privaten und einer öffentlichen IPv4-Adresse konfiguriert ist, oder sicherstellen, dass statische 1:1-NAT-Regeln auf der Edge-Firewall vorhanden sind, zusätzlich zum Öffnen der erforderlichen Ports.

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

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

Überlegungen zu Zoom-Clients und Telefon-Geräten

Clients und Geräte müssen das ZPLS-Modul des Standorts innerhalb des lokalen Netzwerks finden können

Clients und unterstützte Geräte für die Telefon-Überlebensfähigkeit aktiviert während des Startvorgangs das geeignete Failover-ZPLS-Modul aus der Zoom Phone Cloud ermitteln. Das Modul muss jedoch bereits dem Telefonsystem-Standort zugeordnet mit einer intern erkennbaren IPv4-Adresse.

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

Um potenzielle Probleme zu minimieren, sollten Telefon-Geräten über einen lokalen DHCP-Server eine statische oder eine interne IP zugewiesen werden. Wenn einem Gerät keine statische IP zugewiesen ist oder während eines Survivability-Events kein DHCP-Server verfügbar ist, können sich Telefon-Geräte möglicherweise 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 einen OPTIONS-Keepalive-Ping zur Zoom Phone Cloud aufrechterhalten, um den Konnektivitätsstatus des Rechenzentrums zu ermitteln. Bei einem Ausfall sendet der Client weiterhin Keepalive-Nachrichten, um die Wiederkehr des Cloud-Dienstes zu erkennen und die Wiederaufnahme des Normalbetriebs einzuleiten. Dieser Prozess ist automatisch und kann nicht deaktiviert werden.

Firewall- und Netzwerkdatenfluss

Siehe den Abschnitt zu Netzwerkports und Datenfluss.