[mavelot]

La parola Cone non è un acronimo come si può pensare ma è esattamente un "cono" che visivamente rappresenta il NAT di quel tipo....

https://blogs.technet.microsoft.com/mspfe/2012/04/17/understanding-nat-when-setting-up-lync-part-2-stun-and-turn-explained/

[fabiobassa]

@mavelot

Perfetto , grazie, i disegni aiutano sempre meglio a capire !!!!
Molto interessante anche questo link

[Enrico Menotti]

@fabiobassa Con riferimento alla tua risposta al mio punto 3., in realtà non stavo pensando alle porte per il SIP o per i pacchetti dati (voce), ma alla porta di comunicazione dello STUN. La domanda è: come mai se la porta 3478 è bindata a CONE(UDP) allora lo STUN non funziona? Ovviamente perché lo STUN lavora su quella porta lì, ed il router ci fa qualcosa; ma cosa esattamente? Ovvero: che cavolo significa, nel linguaggio del Technicolor, l'applicazione CONE(UDP)? Ho capito bene cosa significhi CONE nel linguaggio della teoria del NAT, ma nello specifico, l'applicazione CONE(UDP) a quale tipo di NAT corrisponde?

@mavelot Grazie per la spiegazione. Sai mica dirmi anche perché il NAT simmetrico si chiami così?

[fabiobassa]

@Enrico Menotti  ora è chiaro:

quella notazione ti sta solo dicendo che su quella porta è "bindato, attaccato... è impegnata " per un nat di tipo "cone" ovvero uno ad uno .
NON ti sta dicendo che applicazione la sta usando , secondo me lo stun interno al tech , visto che per prassi quella è la porta dello stun, e a buona logica la sta usando mmpbxd .
su linux il comando netstat ti direbbe quale applicazione è listening su quella porta. Coi comandi technicolor non so !!!

p.s. anche se è l'argomento di questo 3ad forse stiamo andando un po O.T. casomai apri un altro post e parliamo dei vari tipi di NAT.
Piutosto butteresti giu due righe su quello che hai fatto cosi chi legge ha una mini-guida ?

[Enrico Menotti]

TUTTO FALSO (vedi post sul rasoio di Occam un po' più avanti)


@fabiobassa La mini guida è esattamente quella che ho riportato in uno dei post precedenti, e che quoto qui sotto per riferimento. Più di così non posso certo scrivere, soprattutto perché non ho ancora scoperto chi sia in ascolto, di default, sulla 3478, e quindi non ho ancora la certezza che slegando questa porta dal CONE(UDP) non ci siano poi ripercussioni sul funzionamento normale del VoIP del router (anche se non mi pare proprio, sulla base delle prove empiriche che ho fatto in questi giorni).

1. La porta std dello STUN è la 3478, e così è impostata su Zoiper; ma andando sul router con telnet (basta l'Administrator fornito di default dalla TIM, non serve rootarlo, certo bisogna modificare il file config abilitando telnet e poi ricaricarlo) si scopre che c'è un bind su quella porta. Precisamente, da
menu -> connection -> bindlist
si trova l'applicazione CONE(UDP), protocollo udp, bindata alla porta 3478. Non ho idea di cosa sia questa applicazione. Ho rimosso il bind (con l'unbind).

2. Sulle opzioni avanzate di Zoiper ho abilitato, sia per SIP che per RTP, l'utilizzo di una porta random sopra il 32000. Non sono sicuro che serva per l'RTP, ma per il SIP serve. A questo punto la domanda è: ma allora la 5060 che è specificata a sinistra, per il SIP, non viene usata? E perché la 5060 non va bene? Forse perché viene acchiappata dal router per il suo VoIP interno?

3. Sulle opzioni avanzate dell'account ho lasciato lo STUN predefinito (stun.zoiper.com) con la porta predefinita (3478), ma ho disabilitato rport (cercando in rete ho trovato indicazioni ufficiali di Zoiper secondo le quali l'rport va bene sostanzialmente per TCP, non tanto per UDP) ed rport media (sempre secondo Zoiper, è l'ultima spiaggia, e non ho trovato indicazioni precise sul funzionamento - dicono solo 'don't use this unless you exactly know what you're doing').

[natalinux]

@Enrico Menotti ciao vorrei capire se con zoiper il numero voip di tim funziona solo sotto copertura WiFi oppure anche dall'esterno fuori casa.

[Enrico Menotti]

@natalinux Io ho provato solo usando la LAN fornita dal router TIM (ovvero, precisamente, sotto WiFi di casa). Nel video che mi avevi indicato tu viene chiaramente detto che per usare il VoIP da fuori casa è stato installato un server VPN sul router. Se non ricordo male era il router TIM da 200 Mb/s, quello nero cioè, che era stato opportunamente rootato (non so come, non sono arrivato fino a lì, anche se avevo cominciato) per poi accedere al Linux sottostante (da qualche parte ho letto che c'è una shell BusyBox installata già di default) ed installare il server VPN. Poi sullo smartphone c'è un client VPN sempre attivo, ed a questo punto si può usare il VoIP come se si fosse sotto il WiFi di casa.

Non esco spesso da casa col mio MacBook Pro. La prossima volta che mi capita, se me lo ricordo, faccio un test (senza VPN). Comunque non mi aspetto che funzioni, sulla base di quanto ho letto in giro nei vari forum; suppongo che la TIM conceda l'utilizzo del VoIP solo ai client che chiamano dall'indirizzo IP assegnato al numero di telefono in questione.

[mavelot]

E' corretto. Il voip si può registrare solo dall' IP in quel momento associato all'utenza

[Enrico Menotti]

Siccome mi piace radermi con il rasoio di Occam, ho voluto fare altri test nell'ottica della minimizzazione della configurazione. Ed ho scoperto che stavo prendendo una grossissima granseola. Ecco cosa è saltato fuori.

1. Non serve toccare minimamente il router TIM. Basta usare il famoso script in Python per recuperare la password VoIP del proprio numero fisso.

2. Ribadisco che io sono su Mac. Nel mio caso, Zoiper aveva le seguenti impostazioni out of the box:

rport spuntato
rport media non spuntato
STUN default, cioè stun.zoiper.com
STUN port 3478
SIP port 5060 (non ricordo se era spuntato il random port)
RTP port 8000 (non ricordo se era spuntato il random port)

Provando a chiamare da Zoiper, l'audio è monodirezionale in uscita, come avevo detto all'inizio. Da qui tutto il casotto di cui sopra. Solo che ho scoperto che il problema è tutto nell'rport: provate a de-spuntare l'rport. Continua a non funzionare, vero? E qua viene il bello: da quanto ho capito, c'è un BUG su Zoiper che fa sì che l'rport NON se ne vada solo de-spuntando la casella relativa, o quantomeno ho verificato che se, dopo aver tolto la spunta, si CHIUDE E RIAPRE Zoiper, magicamente il VoIP funziona benissimo. Con router TIM out of the box, porta STUN 3478, porta SIP 5060 (non random) e porta RTP 8000 (non random).

E si possono fare anche chiamate concorrenti: telefono fisso -> cellulare A in parallelo a Zoiper -> cellulare B, entrambe con lo stesso numero "fisso" in uscita. E si può anche chiamare Zoiper dal fisso, facendo il numero di casa (!), e funziona, ed anche il fisso da Zoiper; l'unico neo è che in questo secondo caso il fisso che riceve non riesce a rifiutare la chiamata, e Zoiper riceve pure lui la richiesta di connessione (se si risponde si incasina, nel senso che mette la chiamata in uscita in attesa o qualcosa del genere, ma non mi pare affatto strano). Utile se siete a letto col computer sulla panza (come me ora e quasi sempre) e volete chiamare la mamma che si trova in cucina con la porta chiusa (come la mia ora e quasi sempre).

Segnalo solo che ad un certo punto, nel fare le prove, il fisso aveva smesso di funzionare (provando a chiamare il mio cellulare partiva la richiesta di chiamata, ma poi dava occupato). Ho risolto senza rebootare il router, ma solo disconnettendo e riconnettendo Internet. Non sono poi riuscito a riprodurre il problema nei test successivi.

Non passate troppo tempo al telefono: fa male all'udito e nuoce alle relazioni sociali.

Buon pomeriggio!

Enrico

 


EDIT

Mi sono accorto che quando si riceve una chiamata sul fisso, dal telefono non si può MAI rifiutare la chiamata. Era così anche con le vecchie linee analogiche?

[Enrico Menotti]

Buongiorno a tutti,

ho fatto un piccolo edit in fondo all'ultimo post qui sopra ^^^. Sapete darmi conferma?

[mavelot]

Si confermo. Con i telefoni analogici non è possibile abbattere la chiamata. Solo con un telefono voip puro è possibile farlo