Newsgroup: it.tlc.telefonia.voip
Titolo: Quali porte devo nattare?

Salve a tutti,
Utilizzo con soddisfazione un Gigaset A580IP con Messagenet come
provider voip, volevo chiedere un chiarimento per quanto riguada la
configurazione del router, in particolar modo delle porte da
forwardare verso l' A580IP, fino a qualche tempo fa usavo il voip solo
in uscita, il telefono squillava su RTG Telecom, e senza nessun tipo
di port forward, il tutto ha sempre funzionato, quando chiamavo usavo
Messagenet e quando mi chiamavano usavo Telecom.
Circa un mese fà ho fatto portabilità del numero Telecom su
Messagenet, utilizzando l'ADSL che condivido con mio fratello,
pensando di dover configuare il Router per poter ricevere le
telefonate (che adesso arrivano da Internet) abbiamo fatto prima delle
prove e senza toccare niente sul Router, il Gigaset A580IP squilla
alle chiamate in ingresso.
Ed io che pensavo che sarebbe rimasto muto, ma quindi in una
configurazione basica Home Lan con 5 Pcin rete, Voip, router, come
istruisco il Router? Quali porte si devono/consigliate di forwardare?
fa lo stesso se lascio così?
ciao
Davide

 fa lo stesso se lascio cos�?
Fa lo stesso a niente, perche' e' cosi' e basta :)
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 di telefonia non va in ascolto su alcuna porta.
Oh, menomale che c'e' qualcuno che la pensa come me...
Qualche tempo fa ho discusso per giorni con mezzo newsgroup che 
sosteneva che senza forwardare le porte in ricezione non avrebbe mai 
funzionato...
Ciao, Piero.

Piero ha scritto:



Mezzo newsgroup? Mi sembra di ricordare che oltre a me ci fosse
solo Ribelle60 che opinava sulla questione. :-)
Posso farti vedere sul linksys sp942 come sulle estensioni siano
indicate le porte *sorgente* sip da usare (di default 5060 per la
prima, 5061 per la seconda (e cosi' analogamente per il gateway
isdn voip con 4 bri), e posso dimostrarti quando vuoi come
bloccando la 5060 in ingresso, telefono o asterisk che sia non "sentono"
piu' le chiamate in arrivo. E come, abilitando solo la 5060 incoming e
bloccando il range udp rtp, le chiamate arrivino si', perche' il
signalling e' aperto, ma l'audio e' perlomeno one-way...
Comunque, per me potete rimanere convinti di cio', lasciandovi sviare
dal fatto che siete di fronte a un gateway/router nat che in qualche
modo *supporta il sip natting*.
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.

 alle chiamate in ingresso.
E l'audio va? Sul router non devi fare niente, allora.


  > monitor del PC? Ho visto che è collegato in modalità analogica.
Alla maggior parte dei router domestici non serve alcuna
configurazione particolare per il SIP.
E' sufficiente configurare nel client (il tuo gigaset) lo STUN server
e il keep alive.
Il primo serve a far sapere al client il tuo vero IP sulla rete
(quello pubblico e non quello privato interno)
e il secondo a mantenere aperto un forward verso una porta UDP del
client per le chiamate entranti.

 di telefonia non va in ascolto su alcuna porta.
E come farebbe a ricevere le chiamate? Perdona il sarcasmo... hai 
riscritto ieri le RFC e non lo hai detto a nessuno?
Come gi� fatto notare da altri e discusso pi� volte un certo client X 
con un dato router/gateway Y potrebbe anche funzionare senza toccare 
nulla grazie a vari meccanismi di supporto ormai comuni nei gateway di 
classe consumer e nel client voip; SIP ALG, STUN, durata delle sessioni 
NAT, etc etc...
Rimane un fatto che l'affermazione <<un "client" voip, per la 
funzionalita' di telefonia non va in ascolto su alcuna porta>> � del 
tutto *falsa*.
-- 
Design for the future, because it will be here sooner than you think.
(C) Eric S. Raymond, from "The Art of Unix Programming"

 fa lo stesso se lascio cosï¿œ?
se funziona tutto non vedo perchï¿œ ti devi sbattere :)
oltretutto ho letto da qualche parte (forse qui) che ï¿œ bene non avere 
porte SIP aperte in ascolto...se qualche port scanner dovesse 
accorgersene potrebbero approfittarne...se ho detto una cavolata 
smentitemi :-)

 -- 
concordo pienamente con te, io ho dovuto "aprire" le porte o avevo sempre 
problemi! 

 E come farebbe a ricevere le chiamate?
Nello stesso modo in cui lo fa il tuo MSN Messenger, il tuo Skype o il 
tuo Facebook...
Rimanendo loggato sul server del provider SIP...
Ciao, Piero.

 Oh, menomale che c'e' qualcuno che la pensa come me...
Confermo. Piuttosto ci possono essere problemi di firmware su alcuni router. 
Con un modello US Robotics ad esempio va fatto un settaggio via telnet per 
far funzionare il voip.
Max max 

 tutto *falsa*.
Ok, puoi dirmi cosa ti fa essere cosi' convinto ? 


 Rimanendo loggato sul server del provider SIP...
Possiamo farla molto breve. Installare un sw sip client e monitorare la
rete del sistema, vedendo se va in ascolto. 


 ascolto ?
...hops !!!
Te lo dico sottovoce: se leggi il capitolo 6 della RFC 3261, vedrai
che un'entita in SIP fa da server e client (UAC, UAS) a seconda se
generi una richiesta o la riceva.
Banalmente il tuo telefono IP fa da client quando tiri su la cornetta
per chiamare la ragazza al cellulare (manda un INVITE) e fa da server
quando la giovane ti sbatte il telefono in faccia (riceve un BYE).
Simmetricamente � un server quando riceve una telefonata e un client
quando chiude la comunicazione per primo.
Poi � vero che i provider fanno del loro meglio per riuscire a digerire
di tutto, per cui, se sono minimamente svegli, tutto funziona con un
NAT/PAT puro con uno sforzo di configurazione lato utente prossimo
allo zero. Per� � sempre meglio comprendere tutti gli elementi in gioco,
chi fa cosa, in modo da riuscire a capire dove mettere le mani quando
gli scenari cambiano.
Esempio capitato la scorsa settimana:
router con SIP ALG bacato che bovinamente sostituisce l'IP pubblico
con l'IP privato e viceversa, ovunque li trovi, anche nel Call-ID
se ci sono, distruggendo la comunicazione. Se usi il client X
che nel call-id scrive ad esempio "peperoni_arrosto", l'ALG
bacato non riesce a fare danni e tutto funziona. Questo NON
vuol dire che l'ALG non vada disattivato e che tutto funzioni
senza fare nulla, ma solo che hai avuto culo. :)
Ciao,
-- 
Virgilio Lattanzi        HARPAX srl
Tel: 
+39 0733 818863
     via Fontanella, 38
Fax: 
+39 0733 819133
     62012 Civitanova Marche MC
WWW: 
www.harpax.com
      ITALY

 bye G.L.
Infatti. Se ne � parlato a lungo e, fra le altre cose, ho portato anche 
un discorso (precedente a quella discussione) dove a me capita la stessa 
cosa perch� il mio router supporta il sip natting inverso, nel senso che 
quando asterisk si logga (e continua a verificare di essere loggato) si 
attiva il natting inverso (chiamiamolo cos�) in modo tale che tutto 
quello che viene diretto da quel particolare ip (e porta chiamata) verso 
il mio router viene automaticamente rediretto verso asterisk.
Questa particolarit� � molto interessante dal punto della sicurezza di 
asterisk: � come avere un nat dinamico legato all'ip che viene chiamato, 
e permette un livello di sicurezza MOLTO pi� alto con poca spesa di 
programmazione.
MA QUESTO NON SIGNIFICA che le porte non debbano essere aperte e 
ruotate: solo che il mio router (e altri, a quanto pare) lo fanno 
comunque in automatico ..... infatti la 5060 e le porte UDP 8000-10000 
sono comunque aperte, da me o attraverso il meccanismo dell'upnp.
E comunque questo automatismo non � sempre presente, e quindi 
SPESSISSIMO mi tocca aprire le porte sui router dei clienti (se non lo 
fornisco io...).
Salud.
-- 
"Non ho paura degli urli dei violenti, ma del silenzio degli onesti"
Martin Luther King.

 
Per fortuna oggi la maggior parte dei router attiva le porte in modalit� 
stealth: sono aperte, ma invisibili. Anche grazie alla reiezione ai ping 
....
Il vero problema che essendo aperte e ruotate su qualcosa, questo 
qualcosa risponde se la domanda � giusta ......


 rete del sistema, vedendo se va in ascolto.
Nessuno ha mai detto che va in ascolto (parlando in termini di TCP/IP), 
cosa che ovviamente non puo' fare, non avendo le porte girate.
Io semplicemente sostengo che puo' ricevere chiamate, esattamente come 
ricevono chiamate i client MSN, Skype, Facebook e simili senza aver 
bisogno di girare porte nel nat del router.
Se io installo MSN (rimosso oramai da tempo...) e qualcuno chiama il mio 
nickname, il mio MSN mi squilla e mi avvisa che mi stanno chiamando (che 
sia poi voce o chat poco cambia).
E nessuna porta va aperta nel router...
Il principio e' lo stesso: il client sta connesso al server e il server 
e' quindi in grado di informarlo se c'e' una chiamata.
Questo se uso un provider.
Ovvio che se voglio accettare chiamate dirette SIP (cosa prevista dallo 
standard, ma altamente sconsigliabile), senza avere un provider che mi 
fornisca una linea, una numerazione e quindi un server a cui 
appoggiarmi, debbo per forza aprire le porte...
Ciao, Piero.

 NAT, etc etc...
Non se ne abbiano a male MarioDS e Piero, pero' e' un po' come ignorare
l'esistenza di un problema molto diffuso fino al recente passato e
credere che non sia mai esistito solo perche' oggi raramente si
verifica. Ci sono in rete anni e anni di post e un sacco di howto. E'
solo una questione di culo non avere incontrato problemi per anni.
BTW, quando sara' adottato tcp/ip v6 in larga scala e ognuno avra' una
subnet pubblica tutta sua, il nat sara' solo un ricordo del passato. :-)
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.

 solo una questione di culo non avere incontrato problemi per anni.
Intanto grazie per tutte le esaustive risposte, anche secondo la mia
opinione in alcuni Router, specialmente i più recenti, supportano
telefoni VoIP. Sia con questo Dlink che con il Router di Alice con
funzioni per il Telefono Aladino VoIP tutto funziona senza toccare
nessuna porta, mentre, se non ricordo male, con un router un Belkin se
non aprivo la porta 5060 non squillava.
grazie ancora
Davide

 non aprivo la porta 5060 non squillava.
Dimenticavo, 
http://www.saore.com/temp/voip.jpg
 il Gigaset A580IP è
stato configurato in questo modo. L'ho STUN è disabilitato, Messagenet
indica nella FAQ di non abilitarlo, 
http://www.messagenet.it/it/voip/sw/siemens.html
ciao
Davide

 bye G.L.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 


 e' quindi in grado di informarlo se c'e' una chiamata.
Gia'.. lo pensavo anche io, ma poi Marzullo mi ha indicato la luce! :)


 Gia'.. lo pensavo anche io, ma poi Marzullo mi ha indicato la luce! :)
Io rimango della mia idea.
Non e' necessario che il router abbia esplicitamente delle funzioni di 
aiuto alle connessioni SIP, per poter funzionare, per quanto esistano 
ovviamente delle situazioni in cui non funziona o funziona male...
Fra l'altro l'unica cosa che quasi sempre funziona e' proprio la 
chiamata (in entrambi i sensi), se ci sono dei problemi e' la successiva 
connessione voce ad averli...
Ciao, Piero.

 verifica.
Tutta la mia discussione e' iniziata per (e si limita ad) una sola cosa: 
la possibilita' di essere chiamato (far squillare il telefono) anche se 
non si e' aperta la relativa porta nel nat verso il client.
Che ci siano e ci siano sempre stati problemi SIP lo so bene, e tante 
volte ne sono capitati anche a me e me ne capiteranno, ma MAI nel far 
squillare l'apparecchio, solitamente e' dopo che ci sono i problemi, 
come audio mancante o solo in un senso, chiamata che cade dopo pochi 
secondi, ecc. ecc.
Ciao, Piero.

 ovviamente delle situazioni in cui non funziona o funziona male...
Puoi anche rimanere della tua idea, ma e' IMHO errata. Giustamente
scrivi che i problemi si verificano nella stragrande maggior parte
dei casi nel flusso rtp, ed e' proprio per quest'ultimo che il router
*deve essere previsto*, perche' deve "aprire" dinamicamente verso
l'apparato, in particolare nelle chiamate entranti, verso porte di
destinazione di cui nulla in questo caso puo' sapere se non con
l'introspezione operata da quello che in "termini netfilter" si
chiama "nat helper".
Il discorso della porta di signalling e' invece piu' semplice, giacche'
nel momento in cui l'apparato si registra, il router banalmente "apre"
verso l'ip e porta sorgente dell'apparato che inizia la comunicazione,
come del resto per ogni protocollo "semplice" che non abbia peculiarita'
particolari (come, al contrario, ftp), senza bisogno di nessun
particolare helper, e siccome poi l'apparecchio si registra
periodicamente e' possibile che il router lasci "aperto" il cammino
abbastanza a lungo, rendendo cosi' possibile ricevere l'invite (o
pensi davvero che l'apparato faccia "polling" sul proxy/server sip?...)
per le chiamate entranti. E cosi' si spiega il perche' il signalling
funzioni quasi sempre (a differenza dell'audio).
Poi, io ci ho sbattuto la testa abbastanza a lungo, e come dice Virgilio
e' bene saperle queste cose perche' prima o poi capitera' (OH, se
capitera'...) e allora non si capira' facilmente il motivo, e ancor piu'
difficilmente se ne verra' a capo.


 appunto prevede anche il TCP.
Si, sempre monitorando quel sw ho notato che le porte TCP non vengono
utilizzate, forse e' opzionale ed andrebbe impostato nel programma,
restano in ascolto ma non vanno mai in connessione, mentre quelle UDP
aumentano quando chiamo o quando rispondo ad una chiamata. Dunque e'
sempre su iniziativa del client che probabilmente le usa per aprire un
nuovo canale di comunicazione con il server, da cui una nuova entry nella
tabella del router, che spiegherebbe la mancata necessita' del nat
statico. A questo punto quel riferimento alle definizioni dell'RFC, dove
un agente client e' anche server, risulterebbe possibile con il client che
diventa server e sfrutta i canali aperti (?)
Ma non capisco la necessita' del SIP natting, aprire automaticamente tutte
le porte verso un peer interno se questo provvede da se a farlo con nuove
comunicazioni ? 


 comunicazioni ?
IMHO: piu' che le RFC su SIP, bisognerebbe andare piu' in la' e vedere
SDP, RTP, e RTCP. Ora, non e' che conosca cosi' approfonditamente i
meccanismi, ma basta vedere che, a quanto ho capito, nella negoziazione
SDP (all'interno di SIP) che i due estremi si scambiano
informazioni del tipo "tu mi dici che mi apri RTP e RTCP alla porta
41567 41568 per il flusso voce da me a te?" "Ok, ti comunico che io
faccio altrettanto per il flusso da te a me e mi metto in ascolto
RTP e RTCP sulla 32767 e 32768, e attendo su quella porta il flusso
audio che mi invierai".
Ora, chiaramente, se una o tutt'e due le parti sono sotto NAT, il
router/firewall e' completamente ignaro di cio', e deve andare a fare
introspezione (qui entra in gioco il "nat helper" apposito per il
particolare protocollo) di quanto passa su SIP/SDP per capire su quale
ip privato e quali porte andare a nattare e aprire dinamicamente per
rtp/rtcp che trasportera' il flusso audio.
Per semplificare le cose (e magari e' anche per quello che i problemi
di nat vanno assottigliandosi) vi e' anche il symmetric rtp, che
utilizza non quattro canali ma due, e che va ad usarne uno per il
controllo e l'altro per la stream multimediale, in ambo le direzioni.
