Configurare un SIP trunk: parametri, registrazione e troubleshooting

Un SIP trunk configurato male non smette di funzionare del tutto: funziona a metà. Le chiamate in uscita passano ma quelle in entrata no, l'audio va in una direzione sola, il trunk cade ogni 30 minuti. Quasi sempre la causa sta in tre o quattro parametri. Vediamoli in ordine.

Registrazione o IP authentication

Sono i due modi in cui il centralino si autentica verso il provider e la scelta condiziona tutto il resto.

Registrazione (register): il PBX invia periodicamente un REGISTER con username e password. È l'opzione obbligata quando il centralino sta dietro NAT o ha un IP dinamico, perché il REGISTER apre e mantiene aperto il binding NAT sul router. Va tarato l'intervallo: un registration expiry di 3600 secondi con un timeout NAT del router di 300 secondi produce trunk che risultano "up" sul PBX ma irraggiungibili dall'esterno. In presenza di NAT, tenere il re-register tra 60 e 120 secondi.

IP authentication (peering): il provider riconosce il centralino dall'indirizzo IP sorgente, senza credenziali. Più robusto e senza il rischio che una password finisca in un dump, ma richiede un IP pubblico statico e che l'IP sia registrato lato provider. È la modalità preferibile quando il PBX ha un IP pubblico dedicato — condizione che si ottiene facilmente se centralino e connettività sono sullo stesso operatore.

I parametri che contano davvero

• Host / proxy: l'FQDN o l'IP del SIP server del provider. Se è un FQDN con record SRV, verificare che il PBX li risolva: molti li ignorano e usano solo l'A record, perdendo il failover.
• Porta: 5060 in chiaro, 5061 per SIP/TLS. Cambiare la porta locale di ascolto (es. 5080) riduce drasticamente il rumore degli scanner SIP, ma non sostituisce un firewall.
• From user / From domain: determinano il CLI presentato. Un From domain sbagliato è la causa numero uno del 403 Forbidden in uscita.
• Contesto in entrata: dove finiscono le chiamate ricevute. Se è impostato su default invece che sul contesto corretto, il provider consegna la chiamata ma il PBX non sa cosa farne.
• Max channels: limita le chiamate simultanee al valore contrattato. Senza questo limite, la chiamata in eccesso viene rifiutata dal provider con un errore poco leggibile.
• Qualify / OPTIONS: il PBX invia OPTIONS periodici per verificare che il trunk sia vivo. Utile per il monitoraggio, ma se il provider non risponde agli OPTIONS il trunk viene marcato down pur essendo funzionante: in quel caso va disattivato.

Codec e DTMF

Sui codec vale una regola semplice: offrire solo quelli che si vogliono davvero usare, in ordine di preferenza. Un elenco lungo aumenta la dimensione dell'SDP e la probabilità di transcoding non voluto. Su connettività in fibra G.711a è la scelta standard in Italia (64 kbps per direzione, circa 87 kbps con overhead RTP/IP); G.729 ha senso solo su link stretti e comporta perdita di qualità e, in alcuni contesti, oneri di licenza.

Per i DTMF il valore corretto è quasi sempre RFC 2833 / RFC 4733 (rfc2833 nella configurazione). I toni inband sopravvivono male alla compressione, e SIP INFO è supportato in modo disomogeneo. Sintomo tipico di DTMF sbagliato: gli IVR esterni non riconoscono i tasti premuti, mentre gli IVR interni funzionano.

NAT: la causa dell'audio monodirezionale

Se il segnale SIP funziona e l'audio si sente solo da un lato, il problema è nell'RTP e quasi sempre nel NAT.

• SIP ALG va disabilitato sul router. Riscrive gli header SIP in modo scorretto e crea più problemi di quanti ne risolva.
• Impostare l'IP pubblico esterno nel PBX (externip o external_media_address) e dichiarare le reti locali (localnet). Senza questo, il PBX annuncia nell'SDP un indirizzo privato che il provider non può raggiungere.
• Aprire il range RTP in uscita — tipicamente UDP 10000-20000 — e verificare che il NAT sia symmetric-friendly.
• Abilitare il keepalive RTP se le chiamate silenziose cadono dopo pochi minuti.

Il modo più affidabile per evitare questa categoria di problemi è eliminare il NAT dal percorso: PBX con IP pubblico e trunk sulla stessa rete dell'operatore.

Errori SIP: cosa significano davvero

Diagnosi in tre passaggi

1. Verificare la registrazione: pjsip show registrations o sip show registry su Asterisk. Stato diverso da Registered significa problema di credenziali o raggiungibilità.
2. Catturare il traffico: sngrep è lo strumento più rapido per vedere il flusso SIP in tempo reale, con il ladder diagram delle chiamate. In alternativa tcpdump -i any -n port 5060 -w /tmp/sip.pcap e analisi in Wireshark.
3. Isolare segnale e media: se l'INVITE e il 200 OK sono corretti ma non c'è audio, il problema è esclusivamente RTP — quindi NAT, firewall o SDP.

Prima di aprire un ticket al provider conviene sempre allegare la cattura SIP della chiamata problematica con orario e numero chiamato: dimezza i tempi di risoluzione.