Un trunk è il confine in cui l'operatore decide quali chiamate il tuo apparato può inviare e ricevere. Se hai un PBX, il centralino aziendale che instrada le tue chiamate, un session border controller, una piattaforma di contact center o qualsiasi altro client SIP, il trunk è il modo in cui le sue chiamate raggiungono il mondo esterno e le chiamate esterne raggiungono lui. Un session border controller è il dispositivo che protegge il bordo di una rete vocale.
La prima domanda di solito è se ne serve davvero uno, e la risposta è sì. Quello che cambia è cosa ci metti dietro.
Ho davvero bisogno di un trunk?
Sì. Ciò che cambia tra le varie configurazioni è il client dal tuo lato, non l'esistenza del trunk.
Ogni chiamata da e verso la rete telefonica ne attraversa uno, perché il trunk è il punto in cui la piattaforma decide se accettare la chiamata. Due configurazioni sono comuni:
- Hai un sistema telefonico. Un PBX, softswitch o piattaforma di contact center che già gestisce le chiamate e ha bisogno di una rotta verso la rete pubblica. Si collega come peer, di solito da un indirizzo fisso, e il suo dial plan, le regole che instradano le chiamate, gestisce il controllo di chiamata.
- Hai del codice applicativo. Vuoi che il tuo software effettui o riceva chiamate senza gestire un'infrastruttura telefonica. Hai comunque bisogno di un trunk, e il componente che ci comunica può essere piccolo: un softphone, un browser, il CLI o un runtime per agenti vocali. Si autentica con una credenziale di sessione a breve durata, un nome utente e una password temporanei per un client SIP, anziché da un apparato su un indirizzo noto.
La distinzione riguarda dove risiede il controllo di chiamata, non la scala, e nessuna delle due configurazioni salta il trunk. Un client leggero ti risparmia la gestione di un sistema telefonico, non la connessione in sé. Gli strumenti stessi di Bird lo dimostrano due volte: il telefono della dashboard e la chiamata di test del CLI sono entrambi client SIP che effettuano chiamate reali attraverso uno dei tuoi trunk.
Il trunk non è nemmeno un'alternativa al API, perché nessun endpoint effettua una chiamata verso una destinazione scelta da te. Cos'è una voice API spiega come la parte di configurazione e la parte di segnalazione si dividono il lavoro.
Cosa fa concretamente un trunk?
Fornisce al tuo apparato un indirizzo a cui inviare le chiamate e decide quali chiamate accettare.
Bird assegna a ogni trunk un dominio SIP fisso, che è ciò che inserisci nel tuo sistema telefonico perché le chiamate vengano associate al trunk. Il tuo apparato invia verso quel dominio su uno dei tre trasporti: UDP o TCP su 5060, oppure TLS su 5061 quando vuoi la segnalazione cifrata in transito.
Un trunk appena creato rifiuta ogni chiamata. Entrambe le direzioni sono disattivate e nessun mittente è autorizzato. È un comportamento predefinito deliberato, non una configurazione incompleta. Un trunk che accettasse chiamate dal momento in cui esiste sarebbe un invito permanente, e le frodi sul traffico lo renderebbero costoso in fretta.
Perché outbound e inbound si configurano separatamente?
Perché sono problemi diversi con modalità di errore diverse, e un trunk gestisce ogni direzione in modo indipendente.
Outbound è il tuo sistema telefonico che effettua chiamate attraverso Bird. Finché non lo abiliti, il trunk rifiuta ogni tentativo in uscita indipendentemente dalle credenziali, quindi una chiamata correttamente autenticata fallisce comunque se la direzione è disattivata.
Inbound è Bird che consegna le chiamate al tuo sistema telefonico per i numeri associati al trunk. Abilitarlo non è sufficiente da solo: un trunk con l'inbound abilitato e senza gateway di consegna rifiuta ogni chiamata in arrivo sui suoi numeri. L'associazione di un numero al trunk si fa sul numero, non sul trunk, ed è l'altra metà che spesso sfugge.
Disattivare le chiamate inbound riporta ogni numero associato al trunk in stato di rifiuto, e riattivarlo non li ripristina. Eliminare il trunk ha lo stesso effetto. L'operazione inversa non è quindi simmetrica: se disattivi l'inbound per un test, pianifica di riassegnare ogni numero dopo, e verifica i numeri anziché dare per scontato che il toggle li abbia ripristinati.
Come decide un trunk chi può inviargli chiamate?
Lo decidono una lista di IP consentiti, l'autenticazione tramite chiave API e le credenziali di sessione. Possono essere combinati, e ciascuno diventa attivo non appena ha almeno una voce.
Una lista di IP consentiti. Aggiungi gli indirizzi pubblici da cui il tuo apparato invia verso SIP. Il filtraggio parte nel momento in cui la lista ha una voce, e da quel punto in poi solo gli intervalli elencati possono inviare chiamate. Per apparati dietro NAT si tratta dell'indirizzo pubblico del router, non di quello privato del sistema telefonico. Le chiamate da indirizzi non in lista vengono rifiutate al livello SIP e di solito non compaiono nel registro chiamate. Un registro vuoto è quindi un sintomo di questo, non la prova che nulla sia stato tentato.
Autenticazione tramite chiave API. Bird sfida la chiamata e il tuo sistema risponde con un hash della password anziché con la password stessa. L'hash viene verificato rispetto a una chiave Bird API con accesso vocale a livello di scrittura. Nel tuo PBX il nome utente è sempre bird e la password è il secret della chiave. Come la lista IP, diventa esclusiva non appena una chiave è autorizzata.
Da questo derivano due dettagli operativi. Rimuovere il permesso vocale da una chiave ne blocca immediatamente l'autenticazione. La chiave resta nella lista consentita del trunk, contrassegnata, così la lista non appare mai funzionante quando non lo è. Ripristinare il permesso la riattiva senza modifiche. Revocare o eliminare la chiave ha effetto immediato su ogni trunk che la consentiva, ed è permanente. Per la rotazione, aggiungi prima la nuova chiave al trunk, sposta il tuo apparato, e revoca la vecchia per ultima.
Credenziali di sessione. Un nome utente e una password SIP a breve durata che rispondono alla stessa sfida senza esporre un secret a lunga durata. Sono disattivate su un trunk appena creato e appartengono allo spazio di lavoro anziché a un singolo trunk. La password viene restituita solo al momento della generazione.
Attivare le credenziali di sessione non cambia il modo in cui si collegano gli apparati in lista consentita. Una chiamata da un indirizzo in lista su un trunk senza chiavi API autorizzate viene comunque ammessa senza alcuna sfida di password. Se intendevi la credenziale come filtro, la lista IP è silenziosamente ancora il filtro.
Perché il mio browser o softphone non riesce ad autenticarsi?
Quasi sempre è l'algoritmo di digest. È l'unica impostazione che fallisce in un modo che sembra un problema di credenziali.
Per impostazione predefinita Bird offre prima SHA-256 e poi MD5, e il tuo apparato risponde con il primo che supporta. Un trunk accetta solo gli algoritmi che offre, quindi restringere l'offerta restringe ciò che può connettersi.
La trappola sono i browser: un browser risponde con MD5 e nient'altro. Un trunk che offre solo SHA-256 rifiuta ogni chiamata dal browser, incluso il telefono della dashboard. Mantieni quindi MD5 nell'offerta di digest su ogni trunk da cui intendi chiamare da un browser, e passa a MD5-only quando un PBX gestisce male una sfida che inizia con SHA-256. Le chiavi API funzionano con entrambi gli algoritmi e non necessitano mai di riemissione quando cambi l'offerta.
Quindi cosa devo configurare?
- Un trunk, qualunque sia la tua configurazione. Ogni chiamata ne attraversa uno, quindi questo passaggio non è opzionale.
- Un peer, se gestisci un sistema telefonico. Collega il PBX o la piattaforma di contact center da un indirizzo fisso e lascia che il suo dial plan controlli le chiamate.
- Un client leggero, se hai del codice applicativo. Un softphone, un browser, il CLI o un runtime per agenti, che si autentica con una credenziale di sessione a breve durata anziché con un indirizzo noto.
- Una regola per il mittente, qualunque cosa tu abbia scelto. Una lista di IP consentiti, una chiave API autorizzata o una credenziale di sessione, ricordando che ciascuna diventa esclusiva non appena ha una voce.
- MD5 mantenuto nell'offerta di digest su ogni trunk da cui intendi chiamare da un browser.
Trunk SIP descrive ogni impostazione e dove trovarla. Client SIP spiega come collegare un singolo client anziché un sistema telefonico, e la risoluzione dei problemi vocali aiuta con le chiamate che non arrivano.
In breve
Ogni percorso verso la rete telefonica attraversa un trunk.
Ciò che cambia è il client dal tuo lato: un sistema telefonico collegato come peer, oppure un client SIP più leggero come un browser o il CLI con una credenziale a breve durata.
Un trunk appena creato rifiuta tutto.
Entrambe le direzioni sono disattivate e non c'è alcun mittente autorizzato finché non ne aggiungi uno. È una scelta deliberata, non un passaggio di configurazione che puoi saltare.
Ogni direzione si abilita separatamente, e l'inbound richiede un gateway.
Un trunk con l'inbound abilitato ma senza gateway di consegna rifiuta ogni chiamata in arrivo sui suoi numeri.
Disattivare l'inbound non si annulla in modo pulito.
Ogni numero associato al trunk torna in stato di rifiuto, e riattivare l'inbound non li ripristina. Riassegna ogni numero manualmente.