Problemi VoIP FTTH TIM + Gigaset + Ubiquti UDM Pro

mtrabo · 2023-01-15T15:23:47+00:00

Come si può intendere da titolo sembra la ricetta per il perfetto disastro. Buona domenica a tutti! Mi servirebbe una mano in più per configurare un Gigaset...

mtrabo

MaxBarbero 20/30 parametri

Hai un server STUN?

MaxBarbero

mtrabo no, il campo server STUN è vuoto e anche NAT Traversal è su no

[cancellato]

mtrabo Hai un server STUN?

STUN serve per fargli individuare il tipo di NAT, IP esterno e la mappatura delle porte. Se fai forwarding la mappatura delle porte la gestisci lì, e il tipo di NAT non ha importanza. Rimane da gestire l'IP esterno - se hai una linea business con l'IP statico puoi di solito configurarlo sull'ATA/base DECT. Dipende poi come il proxy SIP ricava l'IP del client - ci sono vari modi tra i quali estrarlo direttamente dai pacchetti in arrivo.

mtrabo

[cancellato]

Allora, situazione attuale: port forwarding di solo UDP 5060, STUN disattivato e SIP ALG disattivato.

Faccio refresh della registrazione dalla webpage del Gigaset perchè mi dava "Registrazione fallita", provo con una chiamata in ingresso e funziona. Ore 18.08. Contemporaneamente stavo facendo una capture wireshark e vedo la chiamata voip con il flow e tutto. Poi appena metto giù, ore 18.13, vedo una nuova SIP Request: REGISTER che ha come Contact URI l'indirizzo IP privato del Gigaset e quindi ora fallisce pure la registrazione.

[cancellato]

mtrabo vedo una nuova SIP Request: REGISTER che ha come Contact URI l'indirizzo IP privato del Gigaset e quindi ora fallisce pure la registrazione.

Se hai IP statico probabilmente è possibile impostare sul Gigaset qual è l'indirizzo esterno. Altrimenti, se il server non identifica correttamente l'IP sorgente si usa STUN per individuarlo e metterlo nel messaggio SIP. Da quello che vedo però l'UDM sembrerebbe usare NAT simmetrico, vedo post a riguardo usando il PXB VoIP 3CX, e il NAT simmetrico dà problemi con STUN. In teoria STUN si potrebbe usare solo per reperire l'IP e ignorare le porte - però dipende come lo implementa il Gigaset.

Se posti le schermate con le configurazioni relative, mascherando dati sensibili, si può cercare di capire cosa si può fare.

mtrabo

[cancellato]

Grazie!! Eccoti:

Non so se ha senso oscurare anche il proxy. Non ho ancora i syslog purtroppo. Nel caso posso mettere l'interfaccia in inglese, perchè mi è anche venuto il dubbio che alcune info si perdano durante la traduzione all'italiano...

[cancellato]

La configurazione al netto della correttezza degli host mi pare suppergiù ok. Peccato non si possa provare ad impostare l'IP WAN, perché mi rimane sempre il dubbio sul tipo di NAT con STUN.

mtrabo Non so se ha senso oscurare anche il proxy.

Sì - ma c'è un motivo per il quale hai disabilitato l'uso dell'outbound proxy? Prova a metterlo a sempre o anche automatico.

Il tempo di refresh NAT andrebbe adeguato alla durata del mapping NAT del router - bisognerebbe sapere qual è. Questo per evitare di inviare pacchetti troppo spesso, alcuni server non gradiscono.

mtrabo i è anche venuto il dubbio che alcune info si perdano durante la traduzione all'italiano

Purtroppo spesso sì.

mtrabo

mtrabo

Spiegazione delle opzioni dalla guida Gigaset:

Modalità proxy outbound:
Indicare quando deve essere utilizzato il Proxy Outbound.

Sempre: tutti i dati di segnalazione e i dati vocali inviati dal telefono vengono inviati al Proxy Outbound.

Automatico: i dati inviati dal telefono vengono inviati al Proxy Outbound solo se il telefono è collegato ad un router con NAT simmetrico oppure con Firewall bloccante. Se il telefono si trova dietro un NAT asimmetrico, viene usato il server STUN.

Mai: il Proxy Outbound non viene utilizzato.

Se nel campo Indirizzo del server outbound non si inserisce nulla, il telefono si comporta indipendentemente dalla modalità selezionata come Mai.

In realtà non so nemmeno se TIM abbia un parametro server outbound da inserire lì...

mtrabo

[cancellato] dubbio sul tipo di NAT con STUN

A seguito della tua dritta stavo leggendo una guida Gigaset a tal proposito. La giro qui:

symmetric NAT
There is a so-called symmetric NAT, on which the STUN protocol does not work adequately. If a Gigaset VoIP phone is connected behind a symmetric NAT, although it can correctly ascertain the public IP address used for the VoIP protocols, it nevertheless cannot ascertain the public port mappings that the NAT will assign to the VoIP protocols. The Gigaset VoIP phone then assumes that the local ports set up for SIP and RTP also correspond to their public mapping. But this is not necessarily the case. The user can make sure that it is, however, with the following options.

Option: Port Forwarding Rules:
The user can generally program so-called Port Forwarding Rules in the router, which ensure that the VoIP ports used locally in the Gigaset (e.g. 5060 for SIP and 5004 and ff. for RTP) are mapped on the WAN side to the same port numbers. Only the base port can be set up for the RTP port on the Gigaset VoIP phone. Depending on the number of parallel VoIP calls supported, the subsequent even port numbers are used for RTP: 2 for devices that support one VoIP call, 3 for those that support two VoIP calls simultaneously. For example: 5004 is set up as the RTP port. Two parallel VoIP calls are supported. So 5004, 5006 and 5008 are used as RTP ports.

Option: Use of exclusive ports for VoIP protocols:
The user can set up the VoIP ports used locally in the Gigaset (for SIP and RTP) in such a way that no other subscriber in the LAN can use the same ports. With many routers, although by no means all, the ports are not remapped by the NAT in such cases, which means they meet the requirement that the locally set port numbers are also used on the WAN side.

[cancellato] disabilitato l'uso dell'outbound proxy

Dalle prove mi sembrava mutuamente esclusiva con l'impostazione STUN, ma dato che disattivando STUN le SIP REQUEST REGISTER mi escono con IP privato mi sembrava più corretto mantenere STUN e disattivare quello. In più in un altro post qui sul forum un utente aveva un config funzionante con il Gigaset senza quella opzione (qui: https://forum.fibra.click/d/25854-voip-gigaset-c530a-go-problema/13).

[cancellato] Il tempo di refresh NAT andrebbe adeguato alla durata del mapping NAT del router

Dici che c'è troppa differenza? Ecco:

apez84

Prova a imparare i dns Tim se ancora non lo hai fatto

mtrabo

apez84

DNS TIM sia lato UDM Pro che staticamente inseriti nel Gigaset. DNS primario: 151.99.125.1 e DNS secondario: 151.99.0.100. E a dirla tutta sembra andare, perchè comunque spesso su Gigaset la connessione VoIP è registrata correttamente...

Karakurt

Magari non funzionerà, però io con VoIP Olimontel e UDM SE ho queste impostazioni e non ho particolari problemi (a parte alcune volte che devo chiamare una seconda volta per riuscire ad uscire, ma non succede spesso e non ho idea del perché...) :

E niente Port Forwarding.

mtrabo

Karakurt

Utilizzi STUN? E che PBX/telefono VoIP?

[cancellato]

mtrabo A seguito della tua dritta stavo leggendo una guida Gigaset a tal proposito.

Ok, ti chiede di fare forwarding esplicito e "simmetrico" (porta WAN = porta LAN) delle porte RTP/RTCP (per ogni porta pari RTP viene usata automaticamente la successiva porta dispari per RTCP). Quindi se le porte RTP impostate sono 5004-5020, devi fare forwarding delle 5004-5021

Ovviamente anche il firewall deve lasciare passare lo stesso traffico. Eventualmente puoi limitare gli IP di provenienza a quelli TIM.

mtrabo Dalle prove mi sembrava mutuamente esclusiva con l'impostazione STUN

In realtà sono due cose separate, STUN serve lato utente per individuare il NAT, l'outbound proxy è una implementazione per la gestione delle chiamate SIP. Quell'help potrebbe riferirsi ad un proxy outbound che è nella LAN del telefono. Un ISP può usare un outbound proxy lato suo per gestire autenticazione e altri fattori dei client SIP.

mtrabo più in un altro post qui sul forum un utente aveva un config funzionante con il Gigaset senza quella opzione

Sì, lì non è proprio settata. Se TIM dice di impostarlo proverei a usarlo, altrimenti no e lascerei il campo vuoto.

mtrabo Dici che c'è troppa differenza?

Più che altro pare che i server TIM se vedono troppo traffico "non richiesto" blocchino la connessione. Se il mapping UDP dura 400s puoi tranquillamente impostarlo a 120s o anche di più, es 240 o 300s. Il sito TIM per l'expire della register ha addirittura un valore di 86400s (1 giorno).

mtrabo

[cancellato] forwarding delle 5004-5021

Quindi mi consigli forwarding di 5004-5021 e anche 5060? Regole firewall ~~dovrebbero essere automatiche.~~ EDIT: lo sono (per WAN IN). Mi tocca anche farle per WAN OUT anche se default è allow? Magari mappa in modo utile?

[cancellato] limitare gli IP

Tu sai per caso se basta la subnet 88.50.0.0/15?

[cancellato] TIM dice di impostarlo proverei a usarlo

TIM parla di un outbound proxy e di un SIP domain, ma senza dire altro.... onestamente non so bene come giocarmi la config in quei quattro campi sul Gigaset. Sa molto di trial and error

[cancellato] expire della register ha addirittura un valore di 86400s

Però questo non sarebbe il mio "Tempo di refresh registrazione" che ho settato a 9999 poichè max per Gigaset? Quel tempo di refresh nat sul Gigaset si riferisce solo al NAT server integrato nell'UDM Pro? Cioè provo ad aumentare poichè comunque molto meno di 400?

[cancellato]

mtrabo Quindi mi consigli forwarding di 5004-5021 e anche 5060?

Proverei, con STUN per la risoluzione dell'IP esterno, se non c'è altro modo per impostarlo e i server TIM non usano received/rport nell'header per identificare il client.

mtrabo Mi tocca anche farle per WAN OUT anche se default è allow?

No, se il default outbound è allow non serve.

mtrabo Tu sai per caso se basta la subnet 88.50.0.0/15?

Questo non lo so. Il motivo è che se le porte sono aperte prima o poi vedrai arrivare tentativi di VoIP spam e accessi illegali. Vero che la password TIM è estremamente dificile da rompere. Il rischio più che altro sono vulnerabilità del Gigaset.

mtrabo TIM parla di un outbound proxy e di un SIP domain, ma senza dire altro.... onestamente non so bene come giocarmi la config in quei quattro campi sul Gigaset. Sa molto di trial and error

Sì, hai ragione - è possibile che basti mettere solo il proxy e non l'outbound come fatto dall'altro utente. Con il VoIP è spesso "trial & error" perché gli ISP sono molto parchi di informazioni.

mtrabo erò questo non sarebbe il mio "Tempo di refresh registrazione"

Ci sono due "keep-alive". Uno è quello della registrazione SIP, che è appunto il "tempo refresh registrazione", l'altro è quello del mapping NAT - però con le porte aperte questo diventa irrilevante - le porte sono sempre aperte, non c'è bisogno di tenerle aperte, ma se non è disabilitatibile è meglio allungarlo un po' così da non dare "fastidio" al server.

mtrabo

[cancellato] Proverei, con STUN per la risoluzione dell'IP esterno, se non c'è altro modo per impostarlo

Sto impazzendo. Continua a non funzionare... è incredibile. Che non sia il Gigaset che è davvero un cesso. Ho cambiato anche le porte, ma nulla.

Nuove info:

Il syslog server GrayLog che ho tirato su non sembra andare perchè Gigaset non specifica come spedisce i pacchetti di log e ne ricevo 0.
Se tengo sia STUN attivo che il server outbound su AUTOMATICO o su SEMPRE nei vari campi della request ho un misto di ip, sia il pubblico che il privato. Se disattivo STUN, i campi hanno sempre e solo l'indirizzo privato. Il tutto con o senza porte aperte e con o senza SIP ALG.
Ho pure provato a tirare su la pppoe su un pfsense a cui ho collegato solo il Gigaset. Ho fatto il port forwarding della 5060 e del range RTP, static mapping del NAT outbound delle porte RTP. Che STUN sia attivato o meno continua a darmi registrazione OK ma non ricevo chiamate in entrata (solo messaggio SIP, quindi il portatile squilla ma non riesco a rispondere). Voglio piangere.
Sto quasi per comprare un TIM Hub, ma che palle.

[cancellato] Questo non lo so

Tutto chiaro, appena funziona poi faccio le mie ricerche per restringere range.

[cancellato] è possibile che basti mettere solo il proxy e non l'outbound come fatto dall'altro utente

Ti dirò però, se disattivo l'outbound dopo da Wireshark vedo un errore 407 Proxy Authentication Required

[cancellato] è meglio allungarlo un po' così da non dare "fastidio" al server

Questo devo ancora aggiustarlo.

[cancellato]

mtrabo Il syslog server GrayLog che ho tirato su non sembra andare perchè Gigaset non specifica come spedisce i pacchetti di log

Dovrebbe andar bene qualsiasi utility che catturi i dati raw, poi si può capire cosa c'è dentro.

mtrabo ho un misto di ip, sia il pubblico che il privato

Questo "misto" mi preoccupa un po', dipende però di quali campi stiamo parlando. Il firmware del Gigaset è l'ultimo? STUN e ALG possono entrare in conflitto, o l'uno o l'altro. STUN dovrebbe far sì che ci metta l'IP pubblico direttamente, ALG dovrebbe processare i messaggi SIP e cambiare i dati necessari. Le implementazioni ALG possono fare casino se per qualche motivo il messaggio non è proprio come se lo aspettano.

mtrabo static mapping del NAT outbound delle porte RTP.

Intendi static port? Conviene farlo di tutte le porte, SIP e RTP. Qui trovi come configurare pfSense per un PBX VoIP: https://www.3cx.com/docs/pfsense-firewall/

mtrabo Ti dirò però, se disattivo l'outbound dopo da Wireshark vedo un errore 407 Proxy Authentication Required

Può essere che l'outbound proxy sia usato per l'autenticazione.

MaxBarbero

mtrabo Il syslog server GrayLog che ho tirato su non sembra andare perchè Gigaset non specifica come spedisce i pacchetti di log e ne ricevo 0.

In che senso non specifica come spedisce i pacchetti? Di solito basta l'indirizzo del syslog server, la porta è standard a meno che uno non la modifichi

mtrabo Sto quasi per comprare un TIM Hub, ma che palle.

a questo punto prenderei un ATA Grandstream HT801 o HT802, che te ne fai del Tim hub dietro alla UDM?

mtrabo

[cancellato] Questo "misto" mi preoccupa un po', dipende però di quali campi stiamo parlando

Ecco da wireshark:

[cancellato] https://www.3cx.com/docs/pfsense-firewall/

Seguito questa guida, ma nulla. Tra l'altro a casa, stesso Gigaset ma linea Fastweb dietro a pfsense con questa config funziona.

mtrabo

MaxBarbero ATA Grandstream HT801 o HT802

Ma infatti mi sa che finirà così. Però dagli ultimi avanzamenti non credo sia un problema di UDM Pro...

MaxBarbero basta l'indirizzo del syslog server

Ti dirò, era la prima volta che provavo. Hai consigli di altri software diversi da GrayLog? Perchè io ci ho provato, ma non ricevo nessun dato incoming nel server syslog che avevo tirato su....

[cancellato]

mtrabo

Nell Call-ID ha poca importanza - quello dovrebbe essere un ID univoco della chiamata. Sarebbe meglio metterci l'IP pubblico che non può essere duplicato come un IP privato, ma non influisce sul routing delle chiamate.

PS: occhio che sopra si vede il tuo IP pubblico. Non so se è statico.

mtrabo Hai consigli di altri software diversi da GrayLog?

Un po' di tempo fa avevo usato questo https://github.com/MaxBelkov/visualsyslog con un ATA Cisco - funzionava.

Edit: questo è un INVITE sulla mia linea:

Message Header
    Via: SIP/2.0/UDP 151.30.x.x:38532;branch=z9hG4bK-eb60ce91
    From: "+39xxxxxxxxx" <sip:39xxxxxxxxx@windtre.it>;tag=17cd3a85e5e9a806o0
    To: <sip:06xxxxxxxx@windtre.it>
    Remote-Party-ID: "+39xxxxxxxxx" <sip:39xxxxxxxxx@windtre.it>;screen=yes;party=calling
    Call-ID: 94df9fb1-9070a4ca@192.168.201.11
    [Generated Call-ID: 94df9fb1-9070a4ca@192.168.201.11]
    CSeq: 101 INVITE
    Max-Forwards: 70
    Contact: "+39xxxxxxxxx" <sip:39xxxxxxxxx@151.30.x.x:38532;ref=39xxxxxxxxx>
    Expires: 240
    User-Agent: Cisco/SPA112-1.4.1_SR5
    Content-Length: 335
    Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER
    Supported: 100rel, replaces
    Content-Type: application/sdp

Quello che è importante è quello che c'è nel campo VIA - è lì che vedi IP:porta, in questo caso come rilevati da STUN. Nel caso dell Call-ID anche Cisco ci mette l'IP privato. Nella risposta il proxy SIP ha aggiunto il valore "received" con l'IP dal quale ha visto arrivare i pacchetti:

Via: SIP/2.0/UDP 151.30.x.x:38532;received=151.30.x.x;branch=z9hG4bK-4ddad35f

« Pagina precedente Pagina successiva »

Informativa privacy - Informativa cookie - Termini e condizioni - Regolamento - Disclaimer - 🏳️‍🌈 🇵🇸
P.I. IT16712091004 - info@fibraclick.it

♻️ Il server di questo sito è alimentato al 100% con energia rinnovabile