Newsgroup: it.tlc.telefonia.voip
Titolo: Euteliavoip

Posso chiamare ma non ricevo telefonate... cosa può essere? 

 Posso chiamare ma non ricevo telefonate... cosa può essere?
Che il telefono non si è registrato correttamente ?

 Posso chiamare ma non ricevo telefonate... cosa può essere?
Se il problema ti si è presentato solo stasera attendi perchè Telecom 
tramite il risponditore automatico del 187 mi ha comunicato che c'è un 
problema generalizzato e che Telecom lo stà risolvendo.
Ciao, Guido 

 Io uso il computer... Mi dice che è libero... ma riesco solo a chiamare...
forse sei dietro un firewall. prova ad attivare lo stun server.

 forse sei dietro un firewall. prova ad attivare lo stun server.
E' già abilitato!!! 

 
Non hai routato correttamente le porte sul tuo router.
-- 
"Non ho paura degli urli dei violenti, ma del silenzio degli onesti"
Martin Luther King.

 Non hai routato correttamente le porte sul tuo router.
A meno di non avere un centralino (come ho io) in casa, con interni 
fuori casa, non e' assolutamente necessario fare alcunche' sul router 
per far funzionare il VoIP.
Anzi: spesso e' controproducente.
Ne con Eutelia, ne' con altri provider.
Ciao, Piero.

Piero ha scritto:

Se non ruoti la 5060 sull'ip del tuo pc OVVIAMENTE rischi di non 
ricevere le telefonate.
Quello che, appunto, succede.


 Quello che, appunto, succede.
UDP è in uscita? 

 Quello che, appunto, succede.
Ho risolto. Il mio router ha il voip integrato... quindi son fregato! 

Mazzabubů ha scritto:

perchč dovresti essere fregato?
Attiva la porta 5061, che č supportata da Eutelia.....


 Quello che, appunto, succede.
Il suo problema e' sicuramente un altro.
Ciao, Piero.

 UDP è in uscita?
sicuramente in entrata, dato che su quella porta GENERALMENTE viaggia la 
SEGNALAZIONE
:)

Mazzabubù ha scritto:

TCP sulla 5060/5061 in entrata e uscita.
UDP sulle porte per la voce, di solito definite dal software.
Dalla 8000 in su, di solito. Basta guardare le impostazioni.
Ingresso e uscita, ruotate sull'apparecchio che le usa.
Non serve ruotarle se chiami solo, lo devi fare se hai un numero a cui 
ti chiamano.


Piero ha scritto:

Bravo, adesso che hai scritto ragionaci sopra, e vedrai che ti accorgi 
che tu usi il voip solo per chiamare e non per farti chiamare.
Esattamente come con il browser chiami i siti MA NON HAI un sito tuo che 
debba essere visto dall'esterno.
Ora che forse hai compreso, prova a studiare come funzionano i router: 
capirai perchč puoi chiamare e non ricevere se il router non ruota 
correttamente le chiamate, a meno di fare in modo che il tuo software 
tenga costantemente aggiornata la nat.
E chiudiamo qui questa parentesi.


 tenga costantemente aggiornata la nat.
Esiste un apposito parametro nel client che e' il timeout di 
registrazione, che fa si' che il client si riregistri ogni tot secondi.
Se fosse vero quello che dici tu, non potrebbero funzionare i client 
VoIP in reti in cui non sia accessibile il router, come per esempio la 
rete Fastweb, sotto cui invece i client VoIP funzionano.
Del resto basta anche una piccola ricerca con Google per averne la 
conferma...
http://forum.html.it/forum/showthread/t-1316612.html
Men che meno funzionerebbero tutti i vari client VoIP disponibili per i 
vari smartphone (quando mai puoi aprire le porte nei router Vodafone o 
TIM, o nei router dei vari WiFi in giro...), e ti assicuro che 
funzionano ANCHE IN RICEZIONE.
Ciao, Piero.

 (
p.es
. server Linux con Asterisk).
Si'? E come farebbe il terminale voip a capire che sta ricevendo una
chiamata, se non dovesse ricevere nulla sulla porta di signaling,
con una comunicazione iniziata dall'esterno?
AFAIK non c'e' differenza fra un pbx e un terminale.
bye G.L.
-- 
Da it.discussioni.consumatori.tutela:
 > P.S. Quando ci sarà lo switch-off, avrò problemi anche col
 > monitor del PC? Ho visto che è collegato in modalità analogica.

 bye G.L.
Lascia perdere .... sono 25 anni che *DICE* che lavora con i router.
Basta questo per capire che racconta palle.....


 Basta questo per capire che racconta palle.....
Ho detto che sono piu' di 25 anni (per l'esattezza da inizio 1985) che 
faccio QUESTO lavoro, cioe' l'informatico.
Che lavoro con i router ho detto 'dall'alba dei tempi' senza specificare 
anni...
(A dire il vero, direi che molti qui mi dovrebbero conoscere, visto che 
i primi firmware per sbloccare i router Alice/Telecom sono venuti da me: 
non credo di essere l'ultimo arrivato...)
Sicuramente ai tempi dei primi che installavo, l'ADSL non si sapeva 
nemmeno cosa fosse...
Tutti i normali router SOHO e pure quelli non 'normali' (l'ultimo client 
che ho installato era connesso ad un Cisco) sono in grado di gestire 
correttamente il NAT per i client VoIP.
Se e' per questo nemmeno l'FTP, a meno di non attivare la modalita' 
passiva, dovrebbe funzionare, mentre invece solitamente non ha problemi...
E' ribadisco il concetto: NON CAMBIA chiamare e/o essere chiamati...
Ciao, Piero.

 E' ribadisco il concetto: NON CAMBIA chiamare e/o essere chiamati...
Cambia, cambia... Posso fartelo vedere con qualche router o con una
qualunque linux box iptables che faccia da firewall senza che abbia
caricati gli appositi moduli nat e conntrack sip, in assenza dei
quali non basta aprire verso l'esterno, si *deve* aprire esplicitamente
anche verso l'interno porte e intervalli di porte udp.


 AFAIK non c'e' differenza fra un pbx e un terminale.
Se i pbx sono usati come client ovviamente non c'e' nessuna differenza.
Il mio pbx e' usato anche come server per client esterni al nat, per cui 
sono costretto a girare le porte nel router.
Non dico che sia SBAGLIATO farlo, dico che e' inutile per una 
connessione con client interno e server esterno al NAT, se si usa 
correttamente lo STUN (o si imposta l'IP pubblico del router, se 
statico), e se il router ha un NAT piu' o meno standard.
Se dovessi aprire la porta SIP verso i client, ci sarebbe la necessita', 
di impostare IP statici in tutti i client VOIP, e occorrerebbe usare una 
porta diversa per ogni client se fossero piu' di uno...
Oltretutto in questo periodo, avere la porta esterna 5060 girata su un 
client SIP ha come spiacevole risultato nelle continue chiamate entranti 
da cinesi/africani/sudamericani/esteuropei che cercano di intrufolarsi 
nei server Asterisk altrui...
Ciao, Piero.

 Ogni x secondi i client debbono riregistrarsi sul server.
Piccolo appunto, stai confondendo: in udp le connessioni sono stateless.
E a questo punto tocca precisare: quando parlo di connection tracking
non mi riferisco in questo caso al tcp (stateful), ma al fatto che
l'introspezione dei pacchetti rende l'apparato che supporta il natting
di quei protocollo in grado di capire quali porte o intervalli di porte
udp nattare e redirigere verso l'interno.
Il fatto che il router mantenga la porta sip nattata e aperta verso
l'interno a tempo indefinito, indica chiaramente come sia supportato il
natting sip dall'apparato.


 caricati gli appositi moduli nat e conntrack sip
Ne ho una giusto in ufficio, come firewall, sicuramente senza porte 
aperte (anche perche' uso il DHCP).
Mi collego correntemente con il mio cellulare Android con client SIP al 
mio Linux di casa, e ricevo regolarmente le telefonate.
Puo' darsi che ci siano caricati i moduli conntrack SIP, non lo escludo, 
ma se e' cosi' ci sono anche in quasi tutti i router in giro, ed e' 
quello che volevo dimostrare io...
P.S. Ho appena guardato: l'unico modulo 'aggiuntivo' e' ip_conntrack_ftp 
(ma ribadisco che la connessione SIP funziona bidirezionale).
Nemmeno nell'OpenWRT che ho in montagna c'e' l'ip_conntrack_sip, e sono 
sicuro al 100% di aver provato la' con Eutelia e il loro client SIP da 
PC, proprio per un problema di ricezione (adesso Eutelia se ci sono 
problemi non risponde piu' 'numero irraggiungibile', ma 'numero 
inesistente'!), e funzionava perfettamente.
Ciao, Piero.

 natting sip dall'apparato.
Certo, anzi sono quasi sicuro pure io che lo fanno, visto che appunto 
funziona...
Anche se forse non delle connessioni SIP in particolare, ma in genere 
delle UDP.
Ciao, Piero.

 delle UDP.
Ah, che lo faccia su singole connessioni tcp e udp "in genere", e'
scontato. :-)
Il problema si pone quando ci si scontra con protocolli particolari che
hanno bisogno di appositi helper nat (esempio banale del passato, il
protocollo ftp come appunto hai ricordato).
Ora, se e' vero che con la porta di signaling non si dovrebbero aver
problemi in uscita, si possono avere (e si hanno... murphy insegna) sia
con la porta di signaling (specie se non e' tenuta aperta in incoming
dal router) sia *soprattutto* con le porte rtp da aprire dinamicamente
in entrata e uscita (i soliti problemi di no-audio, one-way-audio, e
compagnia bella...).
Con il nat helper sip di linux, si puo' tranquillamente abilitare solo
la 5060 in uscita, il resto fa tutto lui. Senza il nat helper, devo
aprire in uscita, ed in entrata con dest. nat e accept, minimo la 5060/
5061 ed il range di porte rtp definito in rtp.conf di asterisk (o quello
specificato sui telefoni sip qualora direttamente registrati sul provider)


 e sicuramente non avevo accesso ai loro router....
Puoi spiegarmi per favore come hai fatto? Perché era una delle mie 
intenzioni ma ho dovuto rinunciarci in quando non sono mai riuscito a 
ricevere una chiamata. O meglio, il telefono squillava anche, ma poi non 
si sentiva nulla.
Ho anche provato ad aprire la 5060 a usare stun server... niente....
Marco

 si sentiva nulla.
Quando non si sente non e' piu' un problema di SIP, ma di RTP e di NAT.
Succede spesso quel problema, ma indistintamente che sia tu a chiamare o 
a ricevere...
E' il problema piu' comune nell'uso di SIP dietro ad un NAT, ma sopra si 
parlava di ricevere la chiamata piuttosto che effettuarla, non di voce 
mancante (problema che appunto affligge, a volte, sia le chiamate fatte 
che quelle ricevute).
Guarda ho installato da poco un telefono VoIP ad un amico medico, che ha 
un ambulatorio con una ADSL Telecom fornita dalla USL (con relativo 
router Cisco del tutto inaccessibile all'utente), e che non aveva invece 
una linea telefonica voce.
Ha preso un numero da Eutelia e gli ho configurato il telefono (un IP301 
sbloccato).
Nonostante il router inaccessibile (e senza DHCP: ho dovuto impostare un 
IP statico al telefono), e nonostante Eutelia (che e' uno dei provider 
piu' ostici da far funzionare), alla fine funziona tutto correttamente e 
ha potuto comunicare ai pazienti il suo nuovo numero di telefono (che 
funziona sia in chiamata che in ricezione).
Non ho fatto cose particolari, ma in effetti con alcuni router ci sono 
dei problemi.
Resta il fatto che se il telefono si registra correttamente, e' in grado 
sia di chiamare che di ricevere, salvo poi, magari, avere problemi di 
voce nella chiamata.
In sostanza i problemi sono sempre due: la connessione SIP (quella che 
... in sostanza fa squillare il telefono), e poi la connessione RTP (che 
trasporta la voce, e che a volte, spesso purtroppo, non va del tutto o 
e' unidirezionale).
Nel 2007 ho fatto 3 settimane negli USA, e tutti i motel dove dormivo 
(catena Super8) avevano il WiFi gratuito.
Allora avevo un Nokia E65 e ho sempre e regolarmente chiamato in Italia 
via VoIP (non mi sono mai fatto chiamare, pero'...).
Stessa cosa l'anno successivo a Mauritius.
L'anno scorso ho fatto una settimana in un'isola della Thailandia: il 
nostro hotel aveva il WiFi gratuito, ma non c'era verso di passare il 
loro NAT in SIP.
Invece usando un client IAX (protocollo molto meno schizzinoso) ci si 
connetteva benissimo e chiamavo regolarmente l'Italia (purtroppo non 
avevo IAX sul telefono e dovevo usare il PC).
In strada, di fronte all'hotel, c'era un bar con WiFi sempre gratuito, e 
da li' invece il client SIP del mio Nokia funzionava benissimo...
Adesso nel nuovo telefono Android ho finalmente anche un client IAX 
funzionante...
Contropartita dell'IAX e' che e' previsto solo dai server/pbx Asterisk, 
almeno a quanto ne so io.
Nessun gestore VoIP pubblico lo usa (io mi collego al mio Asterisk di casa).
Ciao, Piero.

 casa).
Quindi, detto terra terra, non c'è una procedura sicuramente funzionante 
per telefonare (in tx e rx) in voip da una qualsiasi rete connessa a 
Internet.
Marco

 Internet.
Esatto...
Ciao, Piero.

 Esatto...
Peccato perché sarebbe una svolta molto interessante nel modo di 
comunicare. E' anche probabile che questa limitazione sia voluta.
Marco