- Modificato
Notando l’uptick nelle richieste riguardanti la configurazione del VoIP di Fastweb con il modem libero, ho pensato di scrivere questo breve post che descriva nel (relativo) dettaglio il suo funzionamento per prevenire e curare eventuali problemi di configurazione.
Gli assunti principali sono:
- Avere Fastweb (d’uh)
- Avere attivato il modem libero per vie ufficiali (niente spoofing MAC address o simili)
- Avere IP pubblico (è naturalmente possibile usare il VoIP anche dietro CG-NAT, ma è meno naturale e IMHO avere modem libero senza IP pubblico con Fastweb non ha senso)
- Avere le credenziali VoIP fornite da Fastweb
NAT + SIP Premi per mostrare NAT + SIP Premi per nascondere
Un ulteriore assunto, anche se nascosto, è che qualsiasi tipo di NAT helper (SIP ALG o simili) sia disattivato. Questi ultimi aggiungono complessità che nel caso di Fastweb non è utile ma solo dannosa.
Il punto di vista di questo post sarà un po’ inusuale, seguirò la sequenza di pacchetti come catturata dalla CPE analizzando:
- il flusso, per identificare problemi di NAT e Firewall
- gli headers, per identificare problemi di autenticazione
Legenda indirizzi IP:
- 172.16.15.16: PBX
- 85.18.217.100 (
voip.fastwebnet.it): SIP-F - 85.18.217.108: RTP-F
Registrazione
Questo è il flusso di una registrazione SIP che ha successo. PBX manda un SIP REGISTER iniziale a SIP-F, rappresentato qui sotto.
SIP-F risponde sempre con 401 Unauthorized, che invita PBX a produrre le sue credenziali (tramite una challenge).
PBX risponde nuovamente con un SIP REGISTER, sostanzialmente identico a quello sopra con l’aggiunta della risposta alla challenge. SIP-F risponde con 200 OK se e solo se le credenziali sono accettate.
Ora concentriamoci sugli headers SIP, che sono quasi tutti della forma sip:<user>@<domain>.
Gli headers From e To sono identici, <user> deve essere il proprio numero di telefono, mentre <domain> non ha effetto.
Quello che ci interessa però è l’header Contact: <user> qui non ha importanza, mentre <domain> deve essere il proprio indirizzo IP pubblico (così come l’indirizzo dell’header Via, se presente).
Vediamo ora come configurare le varie componenti per ottenere con successo la registrazione.
PBX (o ATA) Premi per mostrare PBX (o ATA) Premi per nascondere
L’impostazione user deve essere il vostro numero di telefono senza prefisso internazionale.
L’impostazione domain deve essere voip.fastwebnet.it.
Deve essere presente un’impostazione che permetta di inserire l’indirizzo IP pubblico (esterno/di NAT/ecc.), in caso contrario è necessario utilizzare un server STUN (sono tutti funzionalmente identici, trovate una lista qui).
Firewall Premi per mostrare Firewall Premi per nascondere
Bisogna avere una regola che permetta la comunicazione PBX:5060->WAN:5060 (generalmente nelle regole di LAN). È possibile restringere la regola al solo indirizzo voip.fastwebnet.it come destinazione.
NAT Premi per mostrare NAT Premi per nascondere
Bisogna avere una regola di NAT outbound statico PBX:5060->WAN:5060. È possibile restringere la regola al solo indirizzo voip.fastwebnet.it come destinazione.
Problema: Username e password sono corretti, ma gli header Contact e Via non contengono l'indirizzo pubblico e quindi Fastweb non accetta comunque l'autenticazione.
Soluzione: Assicurarsi che l'indirizzo IP pubblico sia correttamente impostato, e che Rewrite Contact headers (o simili) sia attivo. Se non è possibile impostare l'indirizzo IP pubblico, usare STUN. Controllare inoltre che il NAT helper per SIP sia disattivato nella propria CPE (firewall/router/ecc.).
Chiamate in entrata
Questo è il flusso di una chiamata in entrata che ha successo.
Se avete seguito correttamente gli step per la registrazione, gli headers qui saranno automaticamente corretti e non avranno alcun segreto. L’unica cosa a cui fare attenzione è utilizzare i codec indicati da Fastweb, i.e. G711A (o alaw, o PCMA), G729, e G729A.
L’invito per la chiamata (SIP INVITE) arriva da SIP-F, mentre la sessione RTP (l’audio in sé) parte dal nostro PBX.
Vediamo ora come configurare le varie componenti per ottenere con successo una chiamata in entrata.
PBX (o ATA) Premi per mostrare PBX (o ATA) Premi per nascondere
I codecs supportati devono includere almeno uno tra G711A, G729, e G729A.
Firewall Premi per mostrare Firewall Premi per nascondere
Bisogna avere una regola che permetta la comunicazione PBX:<range di porte RTP>->WAN:<range di porte RTP> (generalmente nelle regole di LAN). È possibile restringere la regola al solo indirizzo voip.fastwebnet.it come destinazione.
Inoltre bisogna avere una regola WAN:5060->PBX:5060 (generalmente nelle regole di WAN), che permetta ad INVITE di superare il Firewall. È possibile restringere la regola al solo indirizzo voip.fastwebnet.it come sorgente.
NAT Premi per mostrare NAT Premi per nascondere
Bisogna avere una regola di NAT outbound statico PBX:<range di porte RTP->WAN:<range di porte RTP>. È possibile restringere la regola al solo indirizzo voip.fastwebnet.it come destinazione.
Inoltre bisogna avere una regola di NAT port forward WAN:5060->PBX:5060, che permetta ad INVITE di superare il NAT. È possibile restringere la regola al solo indirizzo voip.fastwebnet.it come sorgente.
Problema: La sessione RTP generalmente è simmetrica, il che significa che come noi ci connettiamo a Fastweb, Fastweb si connette a noi. Se la configurazione del NAT non è corretta questa connessione “inversa” non ha successo.
Sintomo: L'audio funziona in uscita ma non in entrata (dal punto di vista di PBX).
Keepalive Premi per mostrare Keepalive Premi per nascondere
É tecnicamente possibile utilizzare il cosiddetto "hole punching" al posto della regola di NAT port forward sulla porta 5060 (come facciamo con RTP), mantenendo attiva la connessione PBX:5060->SIP-F:5060 (che automaticamente permette anche la connessione inversa, si "apre un buco" nel NAT e nel Firewall).
Questo richiede l'utilizzo di un keepalive (chiamato anche qualify, una sorta di ping continuo), che nel caso di SIP è spesso un pacchetto SIP OPTIONS. SIP-F però non risponde a SIP OPTIONS ben formati, vanificando questa tecnica poiché se non riceve risposta PBX considera la sessione SIP non funzionante. É possibile quindi inviare appositamente SIP OPTIONS malformati, che invece sollecitano una risposta da SIP-F.
Personalmente non trovo questa soluzione elegante e perciò non la uso (essendo sostanzialmente equivalente a una regola di NAT port forward limitata al solo voip.fastwebnet.it), ma è valida.
Chiamate in uscita
Questo è il flusso di una chiamata in uscita che ha successo.
Se avete seguito correttamente gli step per la registrazione, gli headers qui saranno automaticamente corretti e non avranno alcun segreto.
Tutti i flussi partono da PBX, il che rende la configurazione più semplice. Se avete seguito correttamente gli step per le chiamate in entrata, le chiamate in uscita dovrebbero funzionare senza ulteriori aggiustamenti.
Disclaimer 1: Questa è solo una delle possibili configurazioni, ma è IMHO la più semplice nonchè quella che uso personalmente.
Disclaimer 2: Se nonostante abbiate seguito questo post il VoIP ancora non funziona, assicuratevi di aver seguito attentamente questo post.
Disclaimer 3: Se nonostante abbiate seguito il Disclaimer 2 il VoIP ancora non funziona, postare un packet capture che indichi dove si trova l'intoppo è sempre utile. Per ottenere il SIP flow come nelle immagini sopra, su Wireshark andare su Telephony->SIP Flows->Flow sequence.
Disclaimer 4: Se ho scritto qualcosa di sbagliato, per favore correggetemi.
