[milan100]

@FrancYescO si ricordo bene fosse impostata a wan. Quei file di configurazione li ho spulciati in tutte le salse.

[LuKePicci]

Calma, non ha nessun senso aggiungere regole al firewall per poi dire che non "le prende" se non si sa come verificare correttamente la cosa.
I test di "apertura porte" verificano solo che ad un certo indirizzo IP:PORTA ci sia qualcosa che risponde al messaggio sonda. Per cui:
- Se "apri una porta" ovvero acconsenti a traffico entrante da una certa interfaccia verso un'altra con determinate restrizioni su ip e porte di mittente e destinatario stai solo dicendo al firewall che quel tipo di traffico è concesso, ovvero fa eccezione rispetto alla regola di base che è "nega connessioni in ingresso da wan"
- Se tieni una "pota aperta" e dietro quella porta non c'è nulla il test ti dice sempre che è chiusa, quel test non fa un check di apertura porte, fa solo un check di raggiungibilità di un qualsiasi servizio dietro quella porta
- Se la porta è aperta per traffico TCP e dietro c'è un socket TCP aperto allora il check di apertura porte riesce bene perchè al primo pacchetto di connessione ricevuto il servizio risponde col secondo pacchetto dell'handshake di connessione TCP, quindi la porta è data (più o meno inequivocabilmente) come aperta
- Se la porta è aperta per traffico UDP e dietro c'è un socket UDP aperto il check di apertura porte non da risultati concludenti perchè non sa cosa inviare al servizio per far si che esso risponda, un servizio UDP fatto bene resta completamente muto se riceve in ingresso dati che per lui non hanno senso

Se non sai che pesci prendere col firewall ti suggerisco di approfondire sulla documentazione ufficiale: https://openwrt.org/docs/guide-user/firewall/start

[milan100]

@LuKePicci darò un'occhiata alla documentazione. Resta il fatto che,in assenza di "opzioni specifiche",come può essere un server stun,il firewall sarà un problema. In questo modem/router,chiaramente.

In ogni caso,sono riuscito dopo l'ennesimo tentativo,a mettere il tim hub in cascata alla vodafone station,cosi almeno in via temporanea,ho un voip funzionante al 100% ed un Tim hub che si occupa di tutto il resto.

[LuKePicci]

STUN è una tecnologia del passato, non si usa più tranne che in qualche vecchio device incapace di tecniche di traversal moderne. Va da se che STUN è appunto una tecnica di nat traversal e che quindi non ha nulla a che fare col tuo problema visto che non stai avendo problemi a configurare client sip dietro NAT, perchè il NAT del TIM hub sta sul router tra lan e wan, mentre il suo client sip interno (mmpbx) va direttamente su internet da interfaccia wan senza transitare dal router (e dal NAT). Infatti non trovi mai configurato alcun nat traversal (tantomeno STUN) su qualsiasi configurazione di default di un gateway fornito per essere esso stesso il router il NAT della tua rete. Quindi tutto quello che dirò qui sotto sarà una divagazione non inerente il tuo problema originario.

Se vuoi configurare il voip di Vodafone (o di qualsiasi provider) su un client LAN abbastanza vecchiotto, e questo client non sa come sopravvivere dietro NAT se non con l'aiuto di STUN, allora un qualsiasi server STUN andrà bene allo scopo, non è necessario che sia quello di Vodafone (non credo esista), ce ne sono anche di pubblici a disposizione.

Una panoramica aggiornata delle tecniche di NAT traversal la trovi su wikipedia: https://en.wikipedia.org/wiki/NAT_traversal guardati principalmente hole punching, STUN e ICE
Ti suggerisco in particolare i paragrafi "Introduction" e "Overview" della specifica di ICE che sono un buon recap dello stato dell'arte a riguardo https://tools.ietf.org/html/rfc5245

Di solito l'helper )anche chiamato ALG) per sip non da il meglio di se quando c'è da gestire un client dietro NAT, e per questo di solito si preferisce andare con hole punching (anche chiamato "NAT mapping" nei client sip di cisco/linksys) o al limite STUN se il NAT fa il difficile.
Ma quando si tratta di creare le opportune regole di "allow" per il traffico da interfaccia pubblica destinato a se stesso l'helper funziona bene, crea le eccezioni dinamiche che servono senza mettere mano ai campi di segnalazione e tutti vivono felici e contenti.

[oifla1966]

Salve se a qualcuno potrebbe servire sono riuscito a far funzionare anche la parte Voip con vodafone nel mio tim hub dg4132. Ho installato con la procedura autoflashgui-github-dev con firmware AGTHP_2.0.0_CLOSED.rbi impostando poi i vari parametri come da vostra guida.
Testato e funzionante tutto......

[Deghii]

Ragazzi qualcuno è riuscito a risolvere il problema che dopo un tot il voip non riceve piu le chiamate? Perche riesco a navigare su internet e a fare le chiamate ma il voip dopo qualche minuto non mi fa ricevere piu le chiamate . Ho gia provato con quasi tutti i firmware che ci sono 

[simosimone97]

Anche a me si presenta questo problema  qualcuno sa come poterlo risolvere?

[FrancYescO]

Forse non c'entra nulla ma provate a rimuovere dal file /etc/config/mmpbxrvsipnet la riga option user_param_value 'phone'

(fonte: https://www.ilpuntotecnico.com/forum/index.php/topic,81513.msg256962.html#msg256962)

[gacchu]

Ciao a tutti. Ho configurato tutto come da guida, la stato della linea resta sempre "unregistered" (pallino grigio). Verificato e riverificato tutti i parametri di configurazione e sono corretti, sembra quasi che non provi neanche a connettersi. Riporto di seguito i parametri che ho utilizzato:

Firmware: 2.2.001 Ansuel

IMPOSTAZIONI SIP:

Globale
Nome: vodafone
Registrar primario: ims.vodafone.it
Nome dominio: ims.vodafone.it   
Realm:
Porta registrar primario: 5060
Proxy primario: voip1.fixed.vodafone.it
Porta proxy primario: 0
Porta locale: 0
Scadenza: 3600

Linee Telefoniche:
Profilo SIP: sip_profile_2
Nome utente: +39***@ims.vodafone.it
URI: +39***
Password: Pass di 28 caratteri fornita da Vodafone
Visualizza nome: +39***
Rete SIP: vodafone

Mappatura ingresso/uscita:
abilitato spunte su fx1

Codec attivi su fx1:
PCMA
G729
G722

Nel file di log non sono riuscito neanche ad individuare tentativi di connessione falliti.. ho sbagliato qualcosa nelle configurazioni o devo entrare nel vortice dei reset/reimpostazioni/riavvii?

Grazie in anticipo per l'aiuto

[milan100]

Se @gacchu provi a mettere 5060,in porta proxy primario,dovrebbe andare. Ti avviso però che con tutta probabilità,pur funzionando avresti il problema delle chiamate in ingresso. Un problema che pare irrisolvibile per noi che abbiamo Vodafone.

[gacchu]

Avevo già provato, ma non è cambiato nulla.. nel weekend effettuerò altri tentativi. E' un vero peccato, con la VS avevo una connessione 87/19, con il tim hub 170/26.. valori a parte, la reattività in navigazione è tutta un'altra cosa, il wifi è degno di questo nome e non ho le frequentissime disconnessioni che avevo con la VS dovute all'eccessivo numero di periferiche connesse (una quarantina circa).
Spero di riuscire a far funzionare la connessione SIP, altrimenti mi è impossibile effettuare un debug per capire come risolvere il problema dello sleep della ricezione.

Comunque grazie mille per il supporto

[milan100]

Avevo letto di gente a cui effettivamente non si registrava proprio. I dati son quelli,al massimo potresti provare a cambiare il proxy primario con voip2 o 3,a prescindere dai dati che ti hanno fornito. Dopodiché non ti resta che provare con riavvii vari oppure andare di reset. Una soluzione che di solito ha risolto il problema a molti.

Comunque ho fatto tutte le prove possibili ed immaginabili,per settimane. Dopodiché l'ho messo in cascata con la Vodafone station,e buonanotte. Due minuti circa dal riavvio totale del modem,e riesci a ricevere, dopodiché fine. Ma la cosa grave é che sto problema pare irrisolvibile solo con l'operatore Vodafone, perché con gli altri va,e quando non va,la soluzione c'é.

[gacchu]

La mia VS purtroppo non regge la struttura IOT del mio appartamento, ogni due giorni si inchioda e per la gestione domotica di casa non posso proprio andare avanti così.
Oltre a questo c'è una differenza spaventosa sia sul ping che sulla velocità di connessione, quindi, anche se mettere qualcosa in cascata alla VS alleggerirebbe il carico, non trovo sensato mettere due apparati quando (se si riesce a farlo funzionare) ne basta uno.
Se riesco a far funzionare la connessione SIP con i dati che mi ha fornito Vodafone, comincio a fare un po' di debug e magari una pezza per lo sleep delle chiamate in ingresso si trova.

[gacchu]

Da ieri sera ho finalmente i servizi SIP autenticati. Naturalmente anche la mia linea soffre dello sleep delle chiamate in ingresso che inizia dopo circa 60 secondi dalla registrazione.
Mi sono documentato e, da quello che ho capito, la causa più probabile è dovuta al fatto che il  DGA4132 chiude le porte UDP sulle quali non è presente traffico da oltre 60 secondi.
Nel caso in cui il problema fosse questo, le possibili soluzioni sono le seguenti:

1) Effettuare un NAT statico solo per i servizi legati alle connessioni SIP, strada che non è facilmente percorribile e che non è detto che sia risolutiva

2) Individuare se all'interno del servizio mmpbxd è presente la possibilità di impostare una qualche funzione di NAT Keep Alive. Tale funzione è presente anche nei telefoni VOIP più economici, ed è stata implementata nei FrtizBox proprio per evitare questa tipologia di problema. Purtroppo non ho trovato alcuna documentazione su mmpbxd (temo non esista) e non ha senso mettere mano nei file di configurazione andando "a caso". Se qualcuno ha modo di reperire documentazione al riguardo, magari può condividerla qui nel forum.

3) Trovare il modo per evitare che vengano troncate le connessioni UDP senza traffico. Purtroppo non è detto che tale regola sia decisa dal firewall, comunque ho salvato il listato delle regole impostate in iptables (iptables -L) in un file di testo che mi sono spulciato con santa pazienza, ma non ho individuato niente al riguardo. Purtroppo le regole del firewall sono impostate con "fw3", che ha file di configurazione e bash script legati ai servizi sparsi un po' in tutto il file system, quindi verificare tutto richiederà del tempo che al momento non ho.

Prima di tornare a fare prove, volevo capire una cosa che leggendo tutto questo thread non mi è chiara:
Tutti i possessori del DGA4132 hanno il problema delle incoming call funzionanti per i primi 60 secondi o è un problema solo di alcuni?

[natalinux]

ciao qual'è questa porta udp che si chiude?