Uitleg over de keuze tussen afzonderlijke PBX’en, centraal call control, lokale telefoons en verbindingen tussen verschillende locaties.
Bij een 3CX-omgeving met meerdere locaties begint de keuze meestal met één belangrijke vraag: waar moet de call control plaatsvinden? Een Bridge verbindt afzonderlijke PBX’en met elkaar, zodat locaties onderling kunnen bellen. Een SBC verbindt lokale telefoons met een PBX die zich op een andere locatie of in de cloud bevindt. Beide kunnen dus worden gebruikt in een multi-site omgeving, maar ze lossen verschillende vraagstukken op.
Bepaal daarom vóór je de Admin Console opent of iedere locatie een eigen PBX nodig heeft, of dat alle locaties één centraal 3CX-systeem gaan gebruiken. Een vestiging kan bijvoorbeeld eigen extensies, trunks, openingstijden, wachtrijen en lokaal beheer nodig hebben. Een andere locatie heeft misschien alleen bureautoestellen die verbinding moeten maken met een PBX op het hoofdkantoor of in de cloud.
Dat zijn twee verschillende modellen. Zodra duidelijk is waar de PBX en het beheer komen te staan, wordt ook de keuze voor de juiste verbinding een stuk eenvoudiger.
Site Connectivity en PBX-plaatsing
Bij site connectivity gaat het om de manier waarop gesprekken en telefoonverkeer tussen locaties lopen. Bij PBX-plaatsing gaat het om de plek waar extensies, trunks, wachtrijen, openingstijden en call routing worden beheerd. Het verschil is eenvoudig: een Bridge verbindt twee 3CX-systemen, een SBC verbindt telefoons op een locatie met een 3CX-systeem op afstand.
Dat onderscheid is belangrijk. Een Bridge maakt van twee afzonderlijke systemen niet ineens één PBX. Andersom creëert een SBC geen lokale PBX met eigen trunks en call-controlregels. Bepaal dus eerst hoe je de omgeving wilt beheren. Kies daarna de verbindingsmethode die daarbij past.
Bridge of SBC?
Meerdere PBX’en als afzonderlijke systemen: Bridge
Kies voor een Bridge wanneer iedere locatie een afzonderlijk 3CX-systeem moet houden, maar gebruikers wel onderling moeten kunnen bellen. Volgens de huidige 3CX-richtlijnen voor Bridges kunnen twee 3CX-systemen via hun bestaande internetverbinding met elkaar communiceren. Met een prefix of een eigen nummerplan bepaal je vervolgens naar welke vestiging een gesprek wordt gestuurd.
Een Bridge is vooral geschikt wanneer iedere PBX eigen beheerders, trunks, openingstijden, wachtrijen of lokale call-routingregels heeft. De systemen blijven duidelijk van elkaar gescheiden, terwijl gebruikers toch eenvoudig collega’s op andere locaties kunnen bereiken.
Ga in de Admin Console naar Voice & Chat > +Bridge toevoegen. De configuratie werkt met een Master/Slave-relatie, een gedeelde authenticatiewaarde, een outbound prefix en een beveiligde FQDN voor het externe systeem. Wanneer een tunnelverbinding wordt gebruikt, kunnen SIP- en RTP-verkeer via deze tunnel lopen. Leg het nummerplan en de outbound rules vast voordat gebruikers tussen de locaties gaan bellen.
Plan nummering, routing en presence
Een nummerplan met prefixes is relatief eenvoudig. Een gebruiker kiest eerst de prefix van de andere vestiging en daarna het extensienummer. Je kunt ook iedere locatie een eigen nummerreeks geven. Dat kan natuurlijker aanvoelen wanneer iedere vestiging duidelijk herkenbare extensies heeft. Welke methode je ook kiest: de outbound rules, digit stripping en eventuele beperkingen op landcodes moeten aansluiten op het gekozen nummerplan.
Presence is een aparte keuze. Wil je dat gebruikers de status van collega’s op een andere PBX kunnen zien? Schakel dan de Bridge-opties in voor het publiceren en ontvangen van presence-informatie. Ga er niet vanuit dat bellen tussen locaties automatisch zorgt voor een gedeelde directory, gedeelde presence of één centraal call-controlsysteem.
Lokale telefoons verbinden met een externe PBX: SBC
Kies voor een SBC wanneer de PBX in de cloud of op een andere locatie staat, terwijl een groep IP-telefoons lokaal een betrouwbare verbinding met die PBX nodig heeft. Volgens de 3CX SBC-documentatie draait de SBC als lokale service. Deze bundelt het SIP-signaleringsverkeer en RTP-mediaverkeer van de locatie en stuurt dit door naar de externe 3CX-instance.
Voor een nevenvestiging die geen eigen PBX nodig heeft, is dit vaak de eenvoudigste architectuur. De vestiging behoudt de eigen telefoons en het lokale netwerk, terwijl call control, extensies, trunks en beheer centraal blijven. Voor kleinere locaties kan een ondersteunde router phone of het gebruik van de 3CX-apps geschikter zijn dan een afzonderlijke SBC.
Een SBC-host heeft een statisch LAN-IP-adres nodig en moet beschikbaar zijn wanneer de lokale telefoons worden gebruikt. Zie de SBC daarom als onderdeel van het volledige telefoniepad, samen met het LAN, de firewall, DNS en de stroomvoorziening.
Ga in de Admin Console naar Voice & Chat > +Add SBC. Provision de SBC en wijs vervolgens de lokale telefoons eraan toe. Houd daarbij goed voor ogen waarvoor de SBC bedoeld is: connectiviteit voor externe telefoons en firewall traversal. Een SBC creëert geen tweede PBX en kopieert ook geen PBX-configuratie.
Checklist vóór de implementatie
Gebruik een Bridge wanneer iedere locatie een eigen PBX en lokaal beheer nodig heeft, maar er wel gecontroleerd tussen de systemen moet kunnen worden gebeld. Gebruik een SBC wanneer één centrale PBX de extensies, trunks, wachtrijen en policies moet beheren, terwijl de telefoons zich op een andere locatie bevinden.
Hebben vestigingen verschillende openingstijden, lokale wachtrijen of afzonderlijke beheerders? Dan kunnen afzonderlijke PBX’en een logischere scheiding bieden. Is centraal beheer en één gezamenlijk extensiesysteem juist het belangrijkste doel? Dan is één centrale PBX met via SBC verbonden telefoons doorgaans eenvoudiger te beheren.
Plan DNS, trunks, telefoons en tests
DNS is onderdeel van het ontwerp en niet iets wat je pas na de installatie moet regelen. Voor gekoppelde systemen schrijft 3CX beveiligde FQDN’s voor. Voor on-premise implementaties wordt split DNS aanbevolen. Gebruik consequent dezelfde vastgelegde namen voor provisioning van telefoons, toegang via apps, certificaten, Bridge-verbindingen en beheer.
Controleer daarnaast voor iedere locatie de 3CX-firewallrichtlijnen en voer de Firewall Checker uit nadat het netwerkpad is geconfigureerd. Vermijd SIP ALG, configureer de juiste ACL’s en leg vast welke poorten en verbindingen nodig zijn voor trunks, externe telefoons, SBC’s en beheer.
Test ten slotte vanuit het perspectief van de gebruiker. Controleer onder andere bureautoestellen, toegang tot de Web Client, mobiele en desktop-apps, push notifications, wachtrijen, doorschakelingen, IVR’s, noodoproepen, opnames, integraties en presence tussen de verschillende locaties.
Gebruik deze Checklist
Controleer vóór je een architectuur kiest de volgende punten:
- Bridge: afzonderlijke PBX’en moeten gecontroleerd met elkaar kunnen bellen, met een duidelijk nummerplan en eventueel gedeelde presence.
- SBC: lokale IP-telefoons moeten verbinding maken met een externe of cloud-PBX, zonder op die locatie een tweede PBX te installeren.
- Nummering: iedere locatie heeft een vastgelegde extensiereeks, prefix of kiesregel die voor gebruikers duidelijk is.
- Netwerk: iedere locatie beschikt over de juiste FQDN, DNS-configuratie en firewallregels. Ook het volledige telefoniepad is gedocumenteerd.
- Beheer: het is duidelijk wie verantwoordelijk is voor iedere PBX, Bridge, SBC, trunkroute en wijziging in het nummerplan.
- Testen: gesprekken tussen locaties, inkomende en uitgaande gesprekken, presence, toegang via apps en representatieve telefoonfuncties zijn getest.
Veelgemaakte fouten bij multi-site architecturen
Een veelgemaakte fout is een Bridge gebruiken terwijl de locatie eigenlijk onderdeel moet zijn van één centraal extensiesysteem. Het omgekeerde komt ook voor: een SBC inzetten terwijl de vestiging juist een eigen PBX en eigen trunks nodig heeft. Andere bekende valkuilen zijn verschillende locaties ieder hun eigen, niet op elkaar aansluitende nummerplan laten bedenken, een IP-adres gebruiken waar een FQDN nodig is, split DNS overslaan of ervan uitgaan dat bellen tussen locaties automatisch een gedeelde directory of presence oplevert.
Een goede vuistregel is daarom: kijk waar de verantwoordelijkheid voor het gesprek en de call control ligt. Houd de architectuur bovendien overzichtelijk genoeg om deze ook later goed te kunnen beheren. Iedere PBX, Bridge, SBC, DNS-record, trunkroute en nummerregel moet een eigenaar hebben en getest zijn. Kan niemand duidelijk uitleggen hoe een gebruiker op locatie A de juiste extensie of trunk op locatie B bereikt? Dan is het ontwerp nog niet af.
Praat mee
Praat mee over 3CX via onze speciale Partner– of Klanten Forums. Volg ons ook op X en LinkedIn om op de hoogte te blijven van het laatste nieuws en nieuwe releases.
