VoIP Gigaset C530A GO - Problema

@[cancellato] (scusami se ti rompo ogni due per tre ogni volta che leggo "VoIP").

DanySky Cosa e come dovrei settare? sul Router?

No, la query DNS la fa comunque il Gigaset. Ma tramite i record SRV dovrebbe trovarsi tutti i proxy SIP che gli servono e configurarseli da solo, una volta impostata il dominio. Non dovrebbe esserci bisogno di impostarli a mano anche perché possono cambiare dinamicamente, nel caso che ne siano elencati più di uno e uno in quel momento non funzioni. Comunque se sono impostati correttamente dovrebbe funzionare lo stesso. Attenzione però che TIM non usa gli stessi server per tutti gli utenti, dipende anche dalla posizione geografica, IIRC.

DanySky per lo STUN non è abilitato (TIM dice cosi),

Il VoIP non è NAT-friendly. Il motivo è che in alcuni messaggi SIP è necessario ci sia l'IP:porta del dispositivo VoIP, così che dall'altra parte sappiano dove trovarlo, ad esempio per iniziare una chiamata. Quando il dispositivo è dietro NAT - e questo capita quando è in cascata, non quando è collegato direttamente - l'IP:porta che vede è quello privato sulla LAN interna, ma per essere chiamati è necessario che ci sia l'IP:porta pubblico sulla rete internet. STUN serve per permettere al dispositivo VoIP di individuare questi ultimi, se non è statico e impostabile a mano.

Fatto questo è poi necessario che il mapping NAT non venga eliminato dal router - in genere quando non c'è traffico il router lo tiene attivo per un po' ma poi lo elimina per non far crescere troppo la tabella dei mapping NAT. Quanto il mapping rimane attivo dipende dal router, alcuni permettono di modificarlo, molti no, e non è magari nemmeno facile sapere qual è il valore di default.

Ci sono diversi modi per farlo. Uno è quello di fare port forwarding statico, così che il mapping è sempre presente. Ha lo svantaggio che la porta è aperta per tutti - e c'è chi cerca attivamente porte VoIP aperte per chiamare a sbafo o fare VoIP spam (c'è anche questo). Ci vorrebbero quindi delle regole di firewalling per accettare il traffico solo dagli IP di TIM, ad esempio.

L'altro è lasciare che il dispositivo VoIP faccia un poco di traffico ogni tanto, prima che il mapping NAT sia eliminato, per mantenerlo attivo. È quel parametro "Tempo di refresh NAT" che vedi, probabilmente.

Se c'è un log si dovrebbe dargli un'occhiata per capire cosa succede quando non funzionano le chiamate e si deregistra. Puoi provare anche a forzare il protocollo ad UDP, ed evitare che ne tenti altri.

C'è un altro metodo ma richiede supporto specifico dal router principale. Ci sono degli specifici moduli software che sono in grado di intercettare, analizzare e modificare il traffico VoIP aprendo le porte e cambiando gli indirizzi come necessario. A volte non lo fanno correttamente e creano più problemi di quelli che risolvono. Non tutti i router li mettono a disposizione.

DanySky Ho aperto (Port Forwarding) tutte le porte interessate (Porta SIP: 5060, Porta RTP:5004-5008, Porta STUN:3478)

In realtà dovrebbe bastare solo la porta SIP (e solo sul protocollo usato, di solito UDP), le RTP dovrebbero venire aperte solo in caso di chiamata. La STUN è solo in uscita e non serve fare forwarding. Hai provato a impostare il server STUN?

Ci vorrebbe un log per capire qual è l'errore quando non si registra più.

DanySky possibile che non esista un log?

Sotto Stato o Gestione non c'è nulla? A volte se non possono fare un log locale lo possono fare su un syslog remoto, sotto Rete non c'è nulla di utile?

DanySky , dunque è il 530 che ha problemi a connettersi e mantenere attiva la connessione.

Sembra proprio di sì. Purtroppo non ho mai usato il modello in questione e non so dirti di più, bisognerebbe provare a chiedere all'assistenza Gigaset.

Ho lo stesso telefono ed avevo lo stesso problema. Purtroppo l'esempio di configurazione fornito da Gigaset contiene diversi errori.

Ecco la mia configurazione che ad oggi funziona:

La causa principale del mio problema era il valore di 20s impostato per il "NAT Refresh time" (Tempo di refresh NAT). Esaminando, il traffico SIP con wireshark mi sono convinto che il proxy principale di TIM ha un firewall che blocca i messaggi udp a 5060 in ingresso se il cliente (cioè il Gigaset) invia troppi pacchetti per unità di tempo rispetto ad un valore limite. Probabilmente tale limite è stato ridotto da TIM recentemente per far fronte agli attacchi DDOS ai fornitori di servizi VoIP dell'anno scorso.

Comunque che sia, nel mio caso, settando un valori oltre 35s faceva funzionare tutto.

Attenzione però, una volta superata il limite di messaggi TIM, dovresti aspettare un pò prima di riprovare. Purtroppo non so per quanto tempo dura il blocco.

sja1440

Possibile. L'ideale sarebbe conoscere per quanto tempo un router mantiene attivo un mapping NAT UDP e regolare quel valore di conseguenza. Ad esempio un router Draytek mantiene di default un mapping UDP per 180s (lo si ottiene con portmaptime -l), quindi un valore di 120-150s è più che adeguato per rinnovarlo prima che scada. Per altri router può non essere così facile rilevarlo.

[cancellato] Hai ragione.

In realtà il valore del NAT Refresh potrebbe tenere in considerazione:

• settaggio del proprio firewall (porta SIP aperta o non)
• valore del timeout dello stato di una connessione UDP nel proprio firewall
• valore del SIP registration expiry impostata del provider.
• eventuali rate limits impostati sul firewall del provider (come TIM)

Per esempio, uno dei mie servizi VoIP imposta il SIP registration expiry a 60 secondi - in quel caso, probabilmente non serve neanche un NAT refresh. Mentre TIM impone 360s alle mie registrazioni

slowhand

Il campo "Registration refresh time" contiene il valore che viene inviato dal Gigaset a TIM. Il protocolo SIP prevede che è il SIP server (cioe TIM) che decide il valore che vuole usare e lo inserisce nella risposta che manda al Gigaset. (ecco un articolo che lo spiega). Avevo visto che TIM risponde sempre con il valore di 360s. In fatti, ho verificato che con TIM il Gigaset usa effettivamente 360s indipendentemente del valore che inserisco io.

Uso il valore 9999 (il massimo consentito dal Gigaset) perché TIM ha scritto: Expire Time: Minimo 86400 secondi". Di conseguenza ho inserito il valore più grande che potevo.

sja1440 grazie, sì avevo immaginato fosse quello. La cosa scandalosa è che Tim dà tutte le informazioni di configurazione, anche quelle che non servono a quasi niente, e poi non indica il NAT-keep-alive da utilizzare (peggio ancora, lo cambiano e non lo comunicano).

sja1440 sì comunque in linea teorica abbassare il registration expiry per ovviare al problema del NAT-keep-alive non è la maniera corretta, anche se probabilmente funziona. E' TIM che dovrebbe dare i parametri corretti da impostare.

Per chi ha hw Unifi, tipo la dream machine, il timeout di una connessione UDP nel firewall è 180 secondi, come da screenshot allegato la cifra dopo 17 è un countdown che parte da 180 e adesso nel mio caso arriva a 140 (perché ho impostato 40 nei settings del Gigaset) e poi riparte.