Krótki przewodnik po wyborze między osobnymi centralami PBX a scentralizowaną obsługą połączeń i zdalnymi telefonami.
Wdrożenia 3CX w wielu lokalizacjach zazwyczaj zaczynają się od decyzji, gdzie ma się znajdować centrum zarządzania połączeniami. Most (Bridge) łączy osobne centrale PBX, umożliwiając komunikację między oddziałami. Z kolei SBC łączy lokalne telefony z centralą PBX znajdującą się w innej lokalizacji lub w chmurze. Obie opcje sprawdzają się w projektach wielooddziałowych, ale odpowiadają na zupełnie inne potrzeby w zakresie łączności i administracji.
Zanim otworzysz Konsolę administratora, zdecyduj, czy każdy oddział potrzebuje własnej centrali PBX, czy wszystkie lokalizacje powinny korzystać z jednego, centralnego systemu. Oddział może wymagać własnych numerów wewnętrznych, łączy SIP Trunk, godzin pracy, kolejek i lokalnej administracji. Inna lokalizacja może z kolei potrzebować jedynie połączenia swoich telefonów stacjonarnych z centralą PBX zlokalizowaną w centrali firmy lub w chmurze.
To dwa różne modele operacyjne. Wybór metody połączenia po jasnym określeniu modelu PBX znacznie ułatwia późniejsze zaplanowanie numeracji, routingu i sieci.
Oddziel łączność między lokalizacjami od lokalizacji centrali PBX
Łączność między lokalizacjami określa sposób przesyłania połączeń i ruchu telefonicznego. Umiejscowienie centrali PBX definiuje natomiast miejsce zarządzania numerami wewnętrznymi, łączami SIP Trunk, kolejkami, godzinami pracy oraz routingiem. Most łączy dwa osobne systemy 3CX. SBC łączy telefony w jednej lokalizacji z odległym systemem 3CX.
Różnica ta jest kluczowa: most nie zmienia osobnych systemów w jedną centralę PBX, a kontroler SBC nie tworzy lokalnej centrali z własnymi łączami SIP Trunk czy regułami obsługi połączeń. Zacznij od wyboru modelu operacyjnego, a następnie dobierz element łączności, który go obsłuży.
Architektura: Mosty vs SBC
Osobne systemy PBX w poszczególnych lokalizacjach (Mosty)

Wybierz połączenie mostowe (Bridge), gdy każda lokalizacja ma pozostać osobnym systemem 3CX, ale użytkownicy muszą mieć możliwość dzwonienia między oddziałami. Aktualne wytyczne 3CX dotyczące mostów wyjaśniają, że dwa zdalne systemy mogą wykorzystywać istniejące łącze internetowe do połączeń międzyoddziałowych, używając prefiksu lub planu numeracji identyfikującego biuro docelowe.
Most sprawdza się w sytuacjach, gdy każda centrala PBX ma własnych administratorów, łącza SIP Trunk, godziny pracy, kolejki lub lokalne reguły routingu. Wyznacza on wyraźną granicę między systemami, dając użytkownikom prosty sposób na kontakt z współpracownikami w innym oddziale.
Przejdź do: Konsola administratora > Voice & Chat > +Add Bridge (+Dodaj most). Konfiguracja opiera się na relacji Master/Slave, wspólnej wartości uwierzytelniania, prefiksie wychodzącym oraz bezpiecznej nazwie FQDN zdalnego systemu. W przypadku korzystania z połączenia tunelowego ruch SIP i RTP może być przesyłany skonfigurowaną ścieżką tunelu. Zaplanuj numerację i reguły wychodzące przed udostępnieniem systemu użytkownikom.
Zaplanuj numerację, routing i status obecności
Plan oparty na prefiksach jest prosty: użytkownik wybiera prefiks oddziału, a następnie zdalny numer wewnętrzny. Plan oparty na zakresach numerów bywa bardziej naturalny, gdy każde biuro posiada dedykowany zakres. Każde z tych podejść wymaga jednak spójności z regułami wychodzącymi, usuwaniem cyfr oraz ograniczeniami kierunkowych krajowych.
Status obecności wymaga osobnej decyzji. Jeśli użytkownicy mają widzieć status współpracowników z drugiej centrali PBX, włącz opcje mostu odpowiedzialne za publikowanie i odbieranie informacji o obecności. Samo połączenie międzyoddziałowe nie tworzy automatycznie wspólnej książki telefonicznej ani jednolitego systemu zarządzania.
Połącz lokalne telefony ze zdalną centralą PBX (SBC)
Wybierz SBC, gdy centrala PBX znajduje się w chmurze lub w głównej siedzibie, a grupa telefonów IP potrzebuje stabilnego połączenia lokalnego. Serwer 3CX SBC działa jako usługa lokalna, która agreguje sygnalizację SIP i media RTP z danej lokalizacji i przesyła je do zdalnej instancji 3CX.
Jest to najprostszy schemat dla oddziału, który nie potrzebuje własnej centrali PBX. Oddział zachowuje lokalne telefony i sieć LAN, podczas gdy zarządzanie połączeniami, numery wewnętrzne, łącza SIP Trunk i administracja są scentralizowane. W małych oddziałach rolę dedicated SBC może przejąć router phone lub aplikacje 3CX.
Host SBC wymaga statycznego adresu IP w sieci LAN i stałej dostępności. Należy go traktować jako kluczowy element ścieżki połączeniowej – na równi z siecią LAN, zaporą sieciową, DNS i zasilaniem.
W Konsoli administratora przejdź do sekcji Voice & Chat i wybierz +Add SBC (+Dodaj SBC). Skonfiguruj SBC, a następnie przypisz do niego lokalne telefony. Pamiętaj o roli tego rozwiązania: SBC rozwiązuje problemy z łącznością zdalną i przechodzeniem przez zaporę sieciową. Nie tworzy drugiej centrali PBX ani nie powiela jej konfiguracji.
Wdrożenie i lista kontrolna przed uruchomieniem
Użyj połączenia typu Bridge, gdy każda lokalizacja wymaga własnej centrali PBX i lokalnej kontroli przy zachowaniu możliwości dzwonienia między systemami. Użyj kontrolera SBC, gdy organizacja dąży do jednej centrali PBX zarządzającej numerami, łączami, kolejkami i regułami, podczas gdy telefony znajdują się w innej lokalizacji.
Jeśli oddziały wymagają różnych godzin pracy, lokalnych kolejek lub osobnych administratorów, osobne centrale PBX zapewniają wyraźniejszy podział kompetencji. Jeśli głównym celem jest spójna administracja i wspólny system numerów wewnętrznych, scentralizowana centrala PBX z telefonami połączonymi przez SBC będzie prostsza w obsłudze.
Zaplanuj DNS, łącza SIP Trunk, telefony i testy
Rozwiązywanie nazw (DNS) to element projektu, a nie detal powdrożeniowy. System 3CX wymaga bezpiecznych nazw FQDN dla połączonych mostami systemów oraz zaleca podwójny DNS (split DNS) dla wdrożeń lokalnych (on-premise). Używaj tych samych nazw w aprowizacji telefonów, aplikacjach, certyfikatach, połączeniach mostowych i administracji.
Przeanalizuj wymagania dotyczące zapory sieciowej dla każdej lokalizacji i uruchom narzędzie Firewall Checker po skonfigurowaniu ścieżki sieciowej. Unikaj funkcji SIP ALG, zdefiniuj reguły ACL i zanotuj porty wymagane dla łączy SIP Trunk, telefonów zdalnych, SBC oraz administracji.
Na koniec przeprowadź testy z perspektywy użytkownika. Sprawdź telefony stacjonarne, dostęp przez Web Client, aplikacje mobilne i desktopowe, powiadomienia PUSH, kolejki, przekierowania, menu IVR, procedury połączeń alarmowych, nagrania, integracje oraz status obecności między lokalizacjami.
Lista kontrolna decyzji
Przed wyborem architektury upewnij się, że:
- Most (Bridge): Osobne centrale PBX wymagają kontrolowanego dzwonienia międzyoddziałowego, planu numeracji i opcjonalnie wspólnego statusu obecności.
- SBC: Lokalne telefony IP muszą łączyć się ze zdalną lub chmurową centralą PBX bez wdrażania kolejnej centrali w danym miejscu.
- Numeracja: Każdy oddział ma udokumentowany zakres numerów wewnętrznych, prefiks lub reguły wywołań zrozumiałe dla użytkowników.
- Sieć: Każda lokalizacja posiada wymagany FQDN, prawidłowy DNS, reguły na zaporze sieciowej oraz udokumentowaną ścieżkę połączeniową.
- Uprawnienia: Zespół wie, kto odpowiada za poszczególne centrale PBX, mosty, serwery SBC, łącza SIP Trunk i zmiany w numeracji.
- Testy: Zespół zweryfikował połączenia międzyoddziałowe, przychodzące i wychodzące, status obecności, dostęp do aplikacji oraz funkcje telefonów.
Najczęstsze błędy architektoniczne
Do typowych błędów należą: stosowanie połączenia Bridge tam, gdzie potrzebna jest centralizacja numerów; używanie SBC w miejscach wymagających własnej centrali i łączy SIP Trunk; brak spójnego planu numeracji między oddziałami; poleganie na adresach IP zamiast FQDN; pomijanie konfiguracji split DNS oraz zakładanie, że same połączenia międzyoddziałowe automatycznie utworzą wspólną książkę telefoniczną. Złota zasada: zawsze oceniaj, gdzie spoczywa odpowiedzialność za obsługę połączenia.
Zadbaj o przejrzystość architektury. Każda centrala PBX, most, kontroler SBC, rekord DNS, linia trunkowa i reguła numeracji powinny mieć wyznaczonego opiekuna oraz procedurę testową. Jeśli nikt nie jest w stanie wyjaśniać, jak użytkownik z jednej lokalizacji dodzwania się do właściwego numeru w drugiej, projekt wymaga dopracowania.
Dołącz do dyskusji
Dołącz do dyskusji o 3CX na naszym dedykowanym forum dla Partnerów lub Klientów. Obserwuj nas na platformie X oraz LinkedIn, aby być na bieżąco z najnowszymi informacjami i zapowiedziami funkcji 3CX.



