Integrare Microsoft Teams con il centralino esistente è lo scenario più richiesto dalle aziende che usano già Teams per riunioni e chat ma hanno un PBX funzionante, con numerazioni, contratti e telefoni che non ha senso buttare. La risposta tecnica è il Direct Routing con un SBC certificato: un’architettura in cui Teams e centralino convivono, si scambiano le chiamate e condividono la numerazione, con una migrazione che procede per fasi e non per strappi. Vediamo come funziona davvero.

Il problema reale: Teams c’è già, il centralino anche

La maggior parte delle aziende su Microsoft 365 usa Teams ogni giorno, ma la telefonia vive altrove: un centralino IP con i suoi interni, le code, i cordless di reparto, il fax server, i citofoni. Sostituire tutto in un colpo solo significa rischio, formazione forzata e investimenti buttati. Non farlo affatto significa tenere due mondi separati, con i dipendenti che rimbalzano tra l’app e il telefono fisso. La terza via è l’integrazione: Teams diventa il telefono di chi lavora in mobilità e in ufficio moderno, il centralino continua a servire ciò che fa bene, e un apparato di confine tiene insieme il tutto.

L’architettura: l’SBC come ponte a tre vie

Il cuore della soluzione è il Session Border Controller, l’apparato che nel Microsoft Teams Direct Routing collega la telefonia aziendale al Phone System di Microsoft. Nella configurazione di coesistenza l’SBC gestisce tre collegamenti: il trunk verso l’operatore SIP (la rete pubblica), il collegamento SIP verso il centralino esistente e la connessione TLS cifrata verso l’interfaccia Direct Routing di Teams. Le regole di instradamento IP-to-IP configurate sull’SBC decidono il percorso di ogni chiamata: un numero assegnato a un utente Teams viene consegnato a Teams, un interno del centralino resta sul centralino, e le chiamate tra i due mondi transitano internamente senza uscire sulla rete pubblica. L’SBC gestisce anche le differenze tecniche tra i due lati: la conversione tra i codec, il passaggio tra RTP e SRTP e le varianti del protocollo SIP che centralino e Teams parlano in modo diverso.

Perché tutto questo funzioni servono tre ingredienti verificati: un SBC presente nell’elenco degli apparati certificati da Microsoft per il Direct Routing, come i modelli AudioCodes Mediant e Patton SmartNode con cui lavora Netframe; un dominio e un certificato TLS pubblico intestati al nome dell’SBC; e la messa in sicurezza del perimetro, per cui rimandiamo alla guida sulla configurazione sicura dell’SBC.

I tre scenari di coesistenza

Scenario	Come funziona	Per chi ha senso
Coesistenza per gruppi	Una parte degli utenti telefona da Teams, il resto dal centralino; l’SBC instrada per numerazione	Migrazioni graduali, uffici più produzione
Teams davanti, PBX dietro	Teams gestisce gli utenti, il centralino resta per esigenze speciali: DECT di reparto, fax, citofoni, dispositivi analogici	Aziende con esigenze industriali o legacy
Migrazione completa per fasi	Il centralino viene svuotato un reparto alla volta fino alla dismissione, l’SBC resta come confine verso l’operatore	Chi punta a Teams come unico sistema

In tutti e tre gli scenari vale la stessa regola: la numerazione geografica resta la vostra. I numeri si spostano tra centralino e Teams cambiando le regole di instradamento sull’SBC e l’assegnazione nel tenant Microsoft, non con nuove portabilità a ogni fase.

Come procede una migrazione ben fatta

Il percorso collaudato parte dall’assessment: censimento di numerazioni, interni, code, dispositivi speciali e contratti con l’operatore, come descritto nella guida all’integrazione della telefonia aziendale. Segue la messa in opera dell’SBC con il pairing verso Teams, verificato con lo scambio dei messaggi OPTIONS tra apparato e nodi Microsoft. Poi il pilota: un gruppo ristretto di utenti passa a Teams Phone con i propri numeri, si misurano qualità e casi d’uso reali, si correggono le regole. Da lì l’estensione procede un reparto alla volta, con il centralino che continua a fare il suo lavoro per tutto il tempo necessario. Due accortezze completano il progetto: la sopravvivenza locale, cioè la capacità di continuare a chiamare la rete pubblica anche se la connettività verso il cloud Microsoft si interrompe temporaneamente, e la qualità del servizio sulla rete, perché la voce su Teams attraversa la stessa infrastruttura dei dati. Sulla stessa architettura, come raccontiamo nella guida al centralino con intelligenza artificiale, si innestano poi voicebot e servizi AI: l’SBC e il trunk SIP sono gli stessi.

Gli errori da evitare

Il primo è instradare “tutto verso tutto” senza regole esplicite: ogni rotta sull’SBC deve avere sorgente e destinazione precise, sia per ordine sia per sicurezza. Il secondo è dimenticare i dispositivi speciali: fax, allarmi, ascensori e POS analogici vanno censiti prima, non scoperti il giorno del passaggio. Il terzo è sottovalutare la sintassi SIP richiesta da Microsoft: il Direct Routing pretende il nome FQDN dell’SBC negli header corretti, e una configurazione imprecisa produce chiamate rifiutate difficili da diagnosticare. Il quarto è trattare la coesistenza come provvisoria e quindi trascurata: finché esiste, è un ambiente di produzione a tutti gli effetti e va monitorato come tale.

Netframe progetta integrazioni tra Teams e centralini esistenti con SBC certificati AudioCodes e Patton, dalla progettazione delle regole di instradamento alla migrazione per fasi. Vuoi capire quale scenario si adatta alla tua azienda? Scrivici a info@netframe.it o chiamaci allo 059 7134794.

Domande frequenti

Posso usare Microsoft Teams come telefono senza dismettere il centralino?

Sì, è esattamente lo scenario del Direct Routing con SBC: Teams e centralino convivono, le chiamate vengono instradate tra i due in base alle regole configurate sull’apparato di confine, e la migrazione degli utenti procede per gruppi senza interruzioni di servizio.

I numeri di telefono restano gli stessi?

Sì. La numerazione geografica esistente rimane invariata: i numeri si spostano tra centralino e Teams modificando le regole di instradamento sull’SBC e l’assegnazione degli utenti nel tenant Microsoft, senza nuove portabilità a ogni fase del progetto.

Serve per forza un SBC certificato Microsoft?

Sì. Microsoft supporta il Direct Routing solo attraverso Session Border Controller presenti nel proprio elenco di apparati validati, con connessione TLS e certificato pubblico. Produttori come AudioCodes e Patton offrono modelli certificati in versione fisica e virtuale.

Cosa succede alle chiamate se cade la connessione verso Microsoft?

Con le soluzioni di sopravvivenza locale, l’SBC può continuare a instradare le chiamate da e verso la rete pubblica attraverso l’operatore SIP anche quando la connettività verso il cloud Microsoft è temporaneamente interrotta, mantenendo operativi i servizi voce essenziali.

Il centralino e Teams possono chiamarsi tra loro come interni?

Sì. Le chiamate tra utenti Teams e interni del centralino transitano internamente attraverso l’SBC, senza uscire sulla rete pubblica e senza costi di traffico, con un piano di numerazione coerente tra i due mondi.

Integrare non significa scegliere tra il vecchio e il nuovo, ma governare il passaggio: l’SBC è il punto in cui questa scelta diventa un’architettura, e la migrazione un percorso misurabile invece di un salto nel vuoto.