Bridges oder SBCs? Die richtige Multi-Site-Architektur wählen

Ein verständlicher Leitfaden zur Auswahl zwischen getrennten PBXs, zentraler Anrufsteuerung, lokalen Telefonen und gemeinsamer Standortanbindung.

Multi-Site 3CX-Bereitstellungen beginnen in der Regel mit einer Entscheidung darüber, wo die Anrufsteuerung angesiedelt sein soll. Eine Bridge verbindet separate PBXs, damit Standorte sich gegenseitig anrufen können. Ein SBC verbindet lokale Telefone mit einer PBX an einem anderen Standort oder in der Cloud. Beide können ein Multi-Site-Design unterstützen, lösen jedoch unterschiedliche Konnektivitäts- und Verwaltungsanforderungen.

Bevor Sie die Admin-Konsole öffnen, entscheiden Sie, ob jeder Standort eine eigene PBX benötigt oder ob sich die Standorte ein zentrales Anrufsteuerungssystem teilen sollen. Eine Niederlassung benötigt möglicherweise eigene Nebenstellen, Trunks, Geschäftszeiten, Warteschleifen und eine lokale Verwaltung. Ein anderer Standort benötigt möglicherweise nur seine Tischtelefone, um eine in der Zentrale oder in der Cloud gehostete PBX zu erreichen.

Dies sind unterschiedliche Betriebsmodelle. Die Wahl der Verbindungsmethode nach Klärung des PBX-Modells macht die Entscheidungen zu Nummerierung, Routing und Netzwerk wesentlich einfacher zu erklären.

Standortanbindung von der PBX-Platzierung trennen

Die Standortanbindung betrifft den Weg von Anrufen und Telefonverkehr zwischen Standorten. Die PBX-Platzierung betrifft den Ort, an dem Nebenstellen, Trunks, Warteschleifen, Geschäftszeiten und Anruf-Routing verwaltet werden. Eine Bridge verbindet zwei 3CX-Systeme. Ein SBC verbindet Telefone an einem Standort mit einem entfernten 3CX-System.

Dieser Unterschied ist wichtig, da eine Bridge separate Systeme nicht in eine einzelne PBX verwandelt und ein SBC keine lokale PBX mit eigenen Trunks oder Anrufsteuerungsrichtlinien erstellt. Beginnen Sie mit dem Betriebsmodell und wählen Sie dann die passende Konnektivitätskomponente.

Architekturentscheidung: Bridges vs. SBCs

Mehrere PBXs als separate Systeme beibehalten (Bridges)

Wählen Sie eine Bridge, wenn jeder Standort ein separates 3CX-System bleiben soll, die Nutzer aber dennoch unternehmensweit telefonieren müssen. Die aktuelle 3CX-Bridge-Anleitung erklärt, dass zwei entfernte Systeme die bestehende Internetverbindung für standortübergreifende Anrufe nutzen können, mit einem Präfix oder Nummerierungsplan, der das Zielbüro identifiziert.

Eine Bridge eignet sich gut, wenn jede PBX eigene Administratoren, Trunks, Geschäftszeiten, Warteschleifen oder lokale Anruf-Routing-Richtlinien hat. Sie hält die Grenze zwischen den Systemen klar aufrecht und bietet Nutzern gleichzeitig eine verlässliche Möglichkeit, Kollegen an einem anderen Standort zu erreichen.

Gehen Sie zu Admin-Konsole > Trunks & Chat > +Bridge hinzufügen. Die Bridge-Konfiguration verwendet eine Master- und Slave-Beziehung, einen gemeinsamen Authentifizierungswert, ein Ausgehendes Präfix und einen sicheren FQDN für das entfernte System. Wenn eine Tunnelverbindung verwendet wird, kann der SIP- und RTP-Datenverkehr über den konfigurierten Tunnelpfad geleitet werden. Planen Sie die Nummerierung und die ausgehenden Regeln, bevor Nutzer mit dem Wählen beginnen.

Nummerierung, Routing und Präsenz planen

Ein präfixbasierter Plan ist leicht zu erklären: Ein Nutzer wählt ein Niederlassungspräfix gefolgt von der entfernten Nebenstelle. Ein standortbasierter Nummerierungsplan kann sich natürlicher anspüren, wenn jedes Büro einen eigenen Nebenstellenbereich besitzt. Jeder Ansatz funktioniert nur, wenn die ausgehenden Regeln, das Ziffernabschneiden und die Ländervorwahl-Einschränkungen mit dem Plan übereinstimmen.

Präsenz ist eine separate Entscheidung. Wenn Nutzer den Status von Kollegen auf der anderen PBX sehen sollen, aktivieren Sie die Bridge-Optionen, die Präsenzinformationen veröffentlichen und empfangen. Gehen Sie nicht davon aus, dass standortübergreifendes Wählen allein ein gemeinsames Verzeichnis oder eine einzelne Anrufsteuerungsebene erstellt.

Lokale Telefone mit einer entfernten PBX verbinden (SBCs)

Wählen Sie einen SBC, wenn die PBX in der Cloud oder an einem anderen Standort bleiben soll, während eine Gruppe von IP-Telefonen eine zuverlässige lokale Verbindung benötigt. Die 3CX-SBC-Anleitung beschreibt den SBC als einen lokalen Dienst, der SIP-Signalisierung und RTP-Medien von einem Standort bündelt und an die entfernte 3CX-Instanz überträgt.

Dies ist oft das einfachste Design für eine Niederlassung, die keine eigene PBX benötigt. Die Niederlassung behält ihre lokalen Telefone und das LAN, während Anrufsteuerung, Nebenstellen, Trunks und Verwaltung zentralisiert bleiben. Für kleinere Standorte ist ein unterstütztes Router-Telefon oder die 3CX-Apps möglicherweise geeigneter als ein dedizierter SBC.

Ein SBC-Host benötigt eine statische LAN-IP und muss immer verfügbar sein, wenn die lokalen Telefone Dienst benötigen. Betrachten Sie ihn als Teil des Telefonpfads, zusammen mit dem LAN, der Firewall, dem DNS und der Stromversorgung, die ihn unterstützen.

Gehen Sie in der Admin-Konsole zu Trunks & Chat und wählen Sie +SBC hinzufügen. Richten Sie den SBC ein und weisen Sie ihm lokale Telefone zu. Halten Sie das Design fokussiert: Der SBC löst die Anbindung entfernter Telefone und den Firewall-Traversal. Er erstellt keine zweite PBX und repliziert keine PBX-Konfiguration.

Implementierungs- & Pre-Deployment-Checkliste

Verwenden Sie eine Bridge, wenn jeder Standort eine eigene PBX-Identität und lokale Kontrolle mit geplantem standortübergreifenden Wählen zwischen den Systemen benötigt. Verwenden Sie einen SBC, wenn die Organisation eine PBX zur Verwaltung von Nebenstellen, Trunks, Warteschleifen und Richtlinien nutzen möchte, während sich die Telefone an einem anderen Standort befinden.

Wenn die Standorte unterschiedliche Geschäftszeiten, lokale Warteschleifen oder separate Administratoren benötigen, bieten separate PBXs möglicherweise die klarere Abgrenzung. Wenn das Hauptziel eine einheitliche Verwaltung und ein gemeinsames Nebenstellensystem ist, ist eine zentrale PBX mit über SBC verbundenen Telefonen meist einfacher zu betreiben.

DNS, Trunks, Telefone und Tests planen

Die Namensauflösung ist Teil des Designs, kein Detail für die Zeit nach der Bereitstellung. Die 3CX-Anleitung erfordert sichere FQDNs für über Bridges verbundene Systeme und empfiehlt Split-DNS für On-Premise-Bereitstellungen. Verwenden Sie dieselben dokumentierten Namen bei der Telefonbereitstellung, dem App-Zugriff, den Zertifikaten, Bridge-Verbindungen und der Verwaltung.

Überprüfen Sie die 3CX-Firewall-Anleitung für jeden Standort und führen Sie den Firewall Checker aus, nachdem der Netzwerkpfad konfiguriert wurde. Vermeiden Sie SIP ALG, definieren Sie die korrekten ACLs und halten Sie fest, welche Ports und Flows für Trunks, entfernte Telefone, SBCs und die Verwaltung erforderlich sind.

Testen Sie schließlich aus der Perspektive des Nutzers. Überprüfen Sie Tischtelefone, Web Client-Zugriff, mobile und Desktop-Apps, Push-Benachrichtigungen, Warteschleifen, Weiterleitungen, IVRs, Notrufprozeduren, Aufzeichnungen, Integrationen und Präsenz über die Standorte hinweg.

Verwenden Sie diese Entscheidungs-Checkliste

Bestätigen Sie vor der Auswahl einer Architektur:

• Bridge: Separate PBXs benötigen kontrolliertes standortübergreifendes Wählen, Nummerierung und möglicherweise gemeinsame Präsenz.
• SBC: Lokale IP-Telefone müssen eine entfernte oder Cloud-PBX erreichen, ohne eine weitere PBX am Standort bereitzustellen.
• Nummerierung: Jeder Standort verfügt über einen dokumentierten Nebenstellenbereich, ein Präfix oder eine Wählregel, die Nutzer verstehen können.
• Netzwerk: Jeder Standort verfügt über den erforderlichen FQDN, das DNS-Verhalten, Firewall-Regeln und einen dokumentierten Telefonpfad.
• Eigentümer: Das Team weiß, wer jede PBX, Bridge, SBC, Trunk-Route und Nummerierungsänderung verwaltet.
• Testen: Das Team hat standortübergreifende Anrufe, eingehende und ausgehende Anrufe, Präsenz, App-Zugriff und repräsentative Telefonfunktionen überprüft.

Häufige Architekturfehler

Typische Fehler sind die Verwendung einer Bridge, wenn ein Standort eigentlich zentrale Nebenstellen benötigt, die Verwendung eines SBC, wenn ein Standort eine eigene PBX und Trunks benötigt, das Zulassen inkompatibler Nummerierungsregeln pro Standort, das Verlassen auf eine IP anstelle des dokumentierten FQDN, das Überspringen von Split-DNS und die Annahme, dass standortübergreifende Anrufe automatisch ein gemeinsames Verzeichnis oder Präsenz erstellen. Faustregel: Bewerten Sie, wo die Verantwortung für den Anruf liegt.

Halten Sie die Architektur klar genug, um sie zu betreiben. Jede PBX, Bridge, jeder SBC, DNS-Eintrag, jede Trunk-Route und Nummerierungsregel sollte einen Eigentümer und einen dokumentierten Test haben. Wenn niemand erklären kann, wie ein Nutzer an einem Standort die richtige Nebenstelle oder den richtigen Trunk an einem anderen Standort erreicht, ist das Design nicht fertiggestellt.

An der Diskussion teilnehmen

Beteiligen Sie sich an der V20-Diskussion in unseren entsprechenden Partner– oder Kundenforen. Folgen Sie uns auf X und LinkedIn, um über Neuigkeiten und neue Funktionen auf dem Laufenden zu bleiben.