Una guida semplice per scegliere tra centralini separati, controllo chiamate centralizzato, telefoni locali e connettività condivisa tra sedi.
Le installazioni 3CX multi-sede iniziano di solito con la scelta di dove debba risiedere il controllo delle chiamate. Un bridge collega centralini separati consentendo alle varie sedi di chiamarsi a vicenda. Un SBC connette i telefoni locali a un centralino situato in un’altra sede o in cloud. Entrambe le soluzioni possono supportare una configurazione multi-sede, ma rispondono a esigenze di connettività e amministrazione differenti.
Prima di aprire la Console di Amministrazione, decidete se ciascuna sede necessiti di un proprio centralino o se le sedi debbano condividere un unico sistema di controllo chiamate centralizzato. Una filiale potrebbe aver bisogno di propri interni, trunk, orari d’ufficio, code e un’amministrazione locale. Un’altra sede potrebbe invece aver bisogno unicamente che i propri telefoni fissi raggiungano un centralino ospitato presso la sede centrale o in cloud.
Si tratta di modelli operativi differenti. Scegliere il metodo di connessione dopo aver chiarito il modello centralino rende molto più semplice spiegare le decisioni relative a numerazione, instradamento e rete.
Separare la connettività di sede dalla collocazione del PBX
La connettività di sede riguarda il modo in cui le chiamate e il traffico telefonico si spostano tra le varie ubicazioni. La collocazione del centralino riguarda il luogo in cui vengono gestiti interni, trunk, code, orari d’ufficio e instradamento delle chiamate. Un bridge connette due sistemi 3CX. Un SBC connette i telefoni di una sede a un sistema 3CX remoto.
Questa distinzione è importante perché un bridge non trasforma sistemi separati in un unico centralino, e un SBC non crea un sistema telefonico locale con i propri trunk o le proprie regole di controllo chiamate. Iniziate definendo il modello operativo, quindi selezionate il componente di connettività che lo supporta.
Scegliere dell’architettura: Bridge vs. SBC
Mantenere più centralini come sistemi separati (Bridge)

Scegliete un bridge quando ciascuna sede deve rimanere un sistema 3CX separato, ma gli utenti hanno comunque la necessità di chiamarsi tra le varie sedi dell’organizzazione. La guida ai bridge 3CX attuale spiega che due sistemi remoti possono utilizzare la connessione Internet esistente per le chiamate tra sedi, tramite un prefisso o un piano di numerazione che identifichi l’ufficio di destinazione.
Un bridge rappresenta la soluzione ideale quando ciascun centralino dispone di propri amministratori, trunk, orari d’ufficio, code o regole di instradamento chiamate locali. Mantiene ben definiti i confini tra i sistemi, offrendo al contempo agli utenti un modo prevedibile per contattare i colleghi presso un’altra sede.
Andate su Console di Amministrazione > Voce e Chat > +Aggiungi Bridge. La configurazione del bridge utilizza un rapporto Master e Slave, un valore di autenticazione condiviso, un prefisso in uscita e un FQDN sicuro per il sistema remoto. Se si utilizza una connessione tunnel, il traffico SIP e RTP può essere instradato attraverso il percorso tunnel configurato. Pianificate la numerazione e le regole di uscita prima che gli utenti inizino a comporre i numeri.
Pianificare numerazione, instradamento e presenza
Un piano basato su prefisso è semplice da spiegare: l’utente compone il prefisso della filiale seguito dall’interno remoto. Un piano di numerazione basato sulla sede può risultare più naturale quando ciascun ufficio possiede un intervallo di interni distinto. Entrambi gli approcci funzionano solo se le regole di uscita, l’eliminazione delle cifre (digit stripping) e le restrizioni per prefisso paese sono coerenti con il piano.
La presenza è una decisione separata. Se gli utenti devono vedere lo stato dei colleghi sull’altro centralino, abilitate le opzioni del bridge che pubblicano e ricevono le informazioni di presenza. Non presupporre che la sola composizione tra sedi crei una rubrica condivisa o un unico piano di controllo delle chiamate.
Connettere i telefoni locali a un PBX remoto (SBC)
Scegliete un SBC quando il centralino deve risiedere in cloud o in un’altra sede, mentre un gruppo di telefoni IP necessita di una connessione locale affidabile. La guida all’SBC 3CX descrive l’SBC come un servizio locale che consolida la segnalazione SIP e i flussi media RTP da un’unica posizione e li invia all’istanza 3CX remota.
Questo è spesso il modello più semplice per una filiale che non necessita di un proprio centralino. La filiale mantiene i propri telefoni locali e la LAN, mentre il controllo delle chiamate, gli interni, i trunk e l’amministrazione rimangono centralizzati. Per le sedi più piccole, un telefono router supportato o le app 3CX potrebbero rivelarsi più indicati rispetto a un SBC dedicato.
Un host SBC necessita di un IP LAN statico e deve essere sempre disponibile ogni volta che i telefoni locali richiedono servizio. Va considerato a tutti gli effetti come parte del percorso telefonico, insieme a LAN, firewall, DNS e alimentazione che lo supportano.
Nella Console di Amministrazione, andate su Voce e Chat e selezionate +Aggiungi SBC. Eseguite il provisioning dell’SBC, quindi assegnatevi i telefoni locali. Mantenete l’architettura focalizzata: l’SBC risolve la connettività dei telefoni remoti e l’attraversamento del firewall (firewall traversal); non crea un secondo centralino né replica la configurazione dello stesso.
Implementazione e Checklist di Pre-Installazione
Utilizzate un bridge quando ciascuna sede necessita di un’identità e di un controllo locale propri, con un’opportuna pianificazione delle chiamate tra i sistemi. Utilizzate un SBC quando l’organizzazione desidera un unico centralinio per gestire interni, trunk, code e regole, mentre i telefoni risiedono in un’altra posizione.
Se le sedi necessitano di orari d’ufficio differenti, code locali o amministratori separati, PBX separati rappresentano la demarcazione più chiara. Se l’obiettivo principale è un’amministrazione uniforme e un sistema di interni condiviso, un PBX centralizzato con telefoni connessi tramite SBC risulta solitamente più facile da gestire.
Pianificare DNS, Trunk, Telefoni e Test
La risoluzione dei nomi fa parte della progettazione, non è un dettaglio post-installazione. Le linee guida 3CX richiedono FQDN sicuri per i sistemi collegati tramite bridge e raccomandano lo Split DNS per le installazioni on-premise. Utilizzate gli stessi nomi documentati nel provisioning dei telefoni, nell’accesso alle app, nei certificati, nelle connessioni bridge e nell’amministrazione.
Consultate la guida al firewall di 3CX per ciascuna sede ed esegui lo strumento Firewall Checker dopo aver configurato il percorso di rete. Evitate il SIP ALG,definite le ACL corrette e registrate quali porte e flussi sono richiesti per trunk, telefoni remoti, SBC e amministrazione.
Infine, effettuate i test dal punto di vista dell’utente. Verificate i telefoni fissi, l’accesso al Web Client, le app mobili e desktop, le notifiche push, le code, i trasferimenti, gli IVR, le procedure per le chiamate di emergenza, le registrazioni, le integrazioni e la presenza tra le varie sedi.
Utilizzare questa checklist decisionale
Prima di scegliere un’architettura, verificate quanto segue:
- Bridge: Centralini o PBX separati necessitano di composizione controllata tra le sedi, di un piano di numerazione e possibilmente della presenza condivisa.
- SBC: I telefoni IP locali devono raggiungere un PBX remoto o in cloud senza dover installare un altro PBX nella sede.
- Numerazione: Ciascuna sede dispone di un intervallo di interni documentato, di un prefisso o di una regola di composizione chiari per gli utenti.
- Rete: Ogni sede dispone dell’FQDN richiesto, del comportamento DNS, delle regole del firewall e di un percorso telefonico documentato.
- Responsabilità: Il team sa chi gestisce ciascun PBX, bridge, SBC, instradamento dei trunk e modifica della numerazione.
- Test: Il team ha verificato le chiamate tra sedi, le chiamate in entrata e in uscita, la presenza, l’accesso alle app e le funzionalità principali dei telefoni.
Errori comuni di architettura
Tra gli errori tipici rientrano l’utilizzo di un bridge quando una sede necessita in realtà di interni centralizzati, l’utilizzo di un SBC quando una sede ha bisogno di un proprio PBX e dei propri trunk, consentire a ciascuna sede di inventare regole di numerazione incompatibili, affidarsi a un indirizzo IP anziché all’FQDN documentato, omettere lo Split DNS e presupporre che le chiamate tra sedi creino automaticamente una rubrica condivisa o la presenza. Regola generale: valuta dove risiede la responsabilità della gestione della chiamata.
Mantenete l’architettura sufficientemente chiara da poter essere gestita. Ogni PBX, bridge, SBC, record DNS, instradamento dei trunk e regola di numerazione dovrebbe avere un referente responsabile e un test documentato. Se nessuno è in grado di spiegare come un utente in una sede possa raggiungere l’interno o il trunk corretto in un’altra sede, il progetto non è da considerarsi completato.
Forum 3CX
Partecipate ai nostri forum dedicati ai Partner o ai clienti. Seguiteci su X e LinkedIn per rimanere aggiornati sulle ultime novità e sui rilasci di funzionalità.



