SBC: cos'è il Session Border Controller e quando serve davvero

Chi si avvicina al VoIP aziendale prima o poi incontra la sigla SBC. Viene descritto come "il firewall del VoIP", ma è una semplificazione che nasconde metà del lavoro che fa davvero. Un Session Border Controller sta sul confine tra due reti SIP e media, e su quel confine fa tre cose: protegge, normalizza e controlla.

Perché un firewall normale non basta

Il SIP è un protocollo di segnalazione testuale che negozia sessioni RTP su porte dinamiche. Un firewall stateful classico vede il traffico SIP sulla 5060 e il flusso RTP su una porta UDP alta apparentemente scorrelata. Senza un componente che legga il corpo SDP, il firewall non sa quali porte aprire e per quanto tempo.

Molti router "risolvono" il problema con il SIP ALG, che riscrive al volo gli header. È una pessima idea: implementazioni approssimative rompono la registrazione, troncano i pacchetti o generano audio monodirezionale. Un SBC fa lo stesso lavoro, ma correttamente e con piena consapevolezza dello stato della chiamata.

La differenza di fondo è questa:

• il firewall filtra pacchetti in base a indirizzi e porte
• il SBC termina la sessione SIP, la ricrea verso l'altro lato e per il tempo della chiamata sa esattamente quali flussi RTP sono legittimi

Le tre funzioni principali

Sicurezza perimetrale. Il SBC nasconde la topologia interna: dall'esterno si vede solo il suo indirizzo, non gli IP degli interni né la versione del PBX. Applica rate limiting sui REGISTER e sugli INVITE, blocca gli scanner SIP che sondano continuamente la porta 5060 e mitiga i tentativi di toll fraud fermando pattern anomali di chiamate verso destinazioni costose.

Interoperabilità. Due implementazioni SIP che seguono lo stesso RFC riescono comunque a non parlarsi. Il SBC normalizza: riscrive header From e To, corregge il formato dei numeri (E.164 contro formato nazionale), forza o rimuove il P-Asserted-Identity, adatta le transazioni quando un lato usa UDP e l'altro TCP o TLS.

Transcoding e gestione media. Se il trunk accetta solo G.711 e gli interni remoti usano G.729 per risparmiare banda, il SBC converte. Fa anche relay RTP, utile quando i due endpoint non riescono a stabilire un flusso diretto.

Quando serve e quando no

Il SBC è realmente necessario in questi scenari:

• Interni remoti su Internet pubblica. Utenti in smart working con IP dinamici e NAT diversi: senza SBC ti trovi a esporre il PBX direttamente in rete, con tutto quello che comporta.
• Trunk multipli da operatori diversi. Ognuno con le sue peculiarità SIP. Il SBC centralizza la normalizzazione e ti evita di rincorrere configurazioni diverse su ogni trunk.
• Migrazioni graduali. Vecchio e nuovo centralino in parallelo, con il SBC che smista in base al numero chiamato.
• Compliance e registrazione. Un punto unico di intercettazione legittima e archiviazione delle chiamate.

Non serve, o serve molto meno, quando:

• il PBX e tutti gli interni sono nella stessa LAN
• il trunk arriva da un collegamento dedicato dell'operatore, senza NAT di mezzo
• il PBX ha già funzioni SBC integrate sufficienti al caso d'uso

Su questo ultimo punto vale la pena essere chiari: piattaforme come 3CX o FreePBX includono meccanismi di gestione NAT, rate limiting e blacklist dinamiche. Per una PMI con un trunk e venti interni, spesso bastano. Il SBC dedicato ha senso quando i flussi diventano molti, eterogenei o quando serve separare nettamente il ruolo di sicurezza da quello di centralino.

SBC e connettività: il punto spesso trascurato

Gran parte della complessità del SBC esiste per compensare una rete ostile: NAT simmetrico, IP dinamici, CGNAT, percorsi Internet imprevedibili. Se il collegamento tra sede e centralino è gestito dallo stesso operatore, con IP pubblico statico e instradamento diretto, molte di queste compensazioni diventano superflue.

È la logica che seguiamo in Velix con i centralini ospitati sulla nostra infrastruttura: quando il cliente è servito dalla nostra rete, il traffico verso il PBX non attraversa Internet pubblica e il comportamento è quello di una LAN estesa. Niente NAT traversal, niente keepalive aggressivi, latenza e jitter sotto controllo perché il percorso è noto.

Cosa guardare in fase di scelta

Se decidi che ti serve un SBC, i parametri da confrontare sono:

• Sessioni concorrenti licenziate, non registrazioni. Sono cose diverse e le licenze si pagano sulle prime.
• Transcoding: quante sessioni possono essere transcodificate contemporaneamente. È l'operazione più costosa in CPU e spesso il limite reale.
• Supporto TLS e SRTP con gestione dei certificati, incluso il rinnovo automatico.
• Alta disponibilità: coppia attiva/passiva con failover che non abbatta le chiamate in corso.
• Logging e tracciamento SIP accessibile: quando qualcosa non funziona, la cattura della segnalazione è l'unico strumento che conta davvero.

Un SBC mal dimensionato o mal configurato è peggio dell'assenza di SBC, perché aggiunge un punto di guasto proprio sul percorso critico delle chiamate. Prima di introdurlo, vale la pena verificare se il problema che stai cercando di risolvere non sia in realtà un problema di rete.