Perché una chiamata SIP si registra su una VPN ma non invia audio

Una registrazione riuscita non dice quasi nulla sull’audio. Un softphone può mantenere un binding valido con il PBX dell’ufficio per ore e consegnare comunque silenzio. Il tunnel trasporta solo i pacchetti che qualcuno vi invia deliberatamente, e una chiamata usa tre percorsi separati: il binding, la configurazione del dialogo e il flusso RTP. Quando li separi, il guasto cade su un percorso invece che sulla parola VPN.

Immagina un portatile su una Wi-Fi domestica che compone un interno dell’ufficio attraverso un tunnel approvato. Il PBX autentica l’utente, accetta il REGISTER e l’interno risulta disponibile, ma la chiamata si connette con un silenzio assoluto in una direzione.

La registrazione lega un contatto, non un percorso media

Una richiesta REGISTER chiede al registrar di memorizzare una corrispondenza tra un indirizzo di registrazione e uno o più URI di contatto. Quella corrispondenza risponde a una domanda ristretta: dove inviare adesso un nuovo dialogo. Non dice nulla su dove appartengono i media, e una registrazione accettata non dimostra che un INVITE successivo porti un indirizzo media raggiungibile. Le registrazioni scadono anche con un timer, quindi un telefono che smette di aggiornare perde le chiamate in arrivo mentre il suo tunnel sembra ancora sano. Osserva la scadenza del contatto, non lo stato del tunnel.

Quando il softphone è dietro il tunnel, l’intestazione del contatto può portare un indirizzo privato. Un PBX che la inoltra a un altro endpoint crea un dialogo diretto a una rete che il chiamato non può raggiungere. Impostare rewrite_contact=yes sull’endpoint PJSIP fa sì che il PBX sostituisca l’indirizzo di origine che ha osservato, ed è spesso la differenza tra uno squillo e un timeout.

Cosa offre l’INVITE e chi può usarlo

Un INVITE con un corpo SDP propone dove il chiamante vuole ricevere i media: un indirizzo, una porta e un elenco di codec. Il chiamato risponde con il proprio indirizzo e la propria porta, poi ciascun lato invia RTP a ciò che l’altro ha proposto. Se il chiamante ha proposto un indirizzo 192.168.x.x che esiste solo nella sua rete domestica, il chiamato non ha dove inviare audio, per pulita che fosse la segnalazione. Il mascheramento riscrive le intestazioni IP quando i pacchetti lasciano un router, ma non riscrive mai il testo dentro un corpo SDP.

Questo divario spiega la classica chiamata unidirezionale: la segnalazione funziona perché entrambi gli endpoint raggiungono il PBX, e l’audio fallisce perché a un endpoint è stato detto di inviare a un indirizzo che esiste solo dietro un altro NAT.

Chi trasporta l’audio è una scelta di configurazione

Segnalazione e media sono ruoli distinti. Un proxy può restare sul percorso di segnalazione per un’intera chiamata e non toccare mai un solo pacchetto RTP. Se il PBX diventa un relè media dipende dalla configurazione, non dalla presenza di un tunnel.

Con i media diretti gli endpoint si scambiano l’RTP da soli, il che funziona bene su una LAN e male quando un lato è dietro un intervallo di porte ristretto.

Impostare direct_media=no spinge il PBX nel percorso media, così entrambe le gambe terminano su un indirizzo che controlla, scambiando banda e CPU con un indirizzamento prevedibile. Quando fa da relè, il PBX deve comunque annunciare un indirizzo raggiungibile. Su un host multi-rete, external_media_address e external_signaling_address in pjsip.conf decidono cosa appare nell’SDP e nelle intestazioni Via. Se li lascia non impostati, il PBX può offrire il proprio indirizzo LAN a un chiamante la cui unica via è il lato lontano del tunnel.

Traccia ogni direzione prima di toccare le impostazioni

Inizia dalla tabella dei socket sul PBX mentre una chiamata è attiva: ss -uanp | grep -E '5060|10000' mostra se le porte RTP sono legate e quale indirizzo locale usano. Se nulla è legato nell’intervallo media, il relè non è attivo e gli endpoint parlano direttamente. Poi cattura dal lato softphone con tcpdump -ni any -s0 udp portrange 10000-20000 -w rtp.pcap. Pacchetti in uscita senza pacchetti in entrata restringono il problema al percorso di ritorno o all’indirizzo che è stato detto all’altro capo di usare, e una cattura vuota significa che i media non hanno mai raggiunto l’interfaccia del tunnel. Una cattura di segnalazione con sngrep risponde all’altra metà mostrando la riga di connessione SDP come è stata inviata.

Confronta l’indirizzo di quella riga di connessione con l’indirizzo verso cui l’altro capo può realmente instradare. Quell’unico confronto risolve la maggior parte delle segnalazioni di audio unidirezionale più in fretta di qualsiasi revisione della configurazione.

La crittografia si ferma al bordo del tunnel

SIP su TLS protegge il salto di segnalazione per cui è stato configurato, SRTP protegge i media quando entrambe le estremità lo negoziano, e il tunnel protegge il traffico tra i propri endpoint. Nessuno di questi concede gli altri. Una chiamata cifrata dentro il tunnel può uscire dal gateway in chiaro verso il PBX, e questa è una scelta di progetto, non un difetto.

Prima di chiudere il ticket, conferma tre cose in ordine: la registrazione è recente, l’SDP porta un indirizzo che l’altro capo può raggiungere e i pacchetti fluiscono in entrambe le direzioni sulle porte media. Se una di queste è falsa, il tunnel non è dove vive il problema. Correggi il percorso che ha fallito, poi ripeti la stessa cattura per confermare la modifica. Conservare le catture prima e dopo rende la prossima segnalazione unidirezionale un controllo di cinque minuti invece di un pomeriggio intero.