Newsgroup: it.tlc.telefonia.voip
Titolo: Asterisk: problema di connessione strano

Hola,
ho un asterisk dietro ad un FW linux che fa nat.
Mi collego a diversi sip providers e (normalmente) durante il giorno non ho
alcun problema.
Le linee funzionano, gli accounts vengono registrati e non ci sono
problemi.
La mattina quando torno in ufficio, l'unico account di un singolo provider
(squillo) me lo trovo con la regitration failed.
Sniffando, noto che il loro asterisk non mi manda più indietro le risposte
come dovrebbe fare sulla 5060 ma su una porta stranissima e alta.
Ovvio che il mio asterisk non riesce a mantenere la registrazione attiva.
Ora, il mio dubbio è il seguente: che diavolo può causare il problema ?
Considerando che per tutto il giorno, dopo il reboot, tutto funziona,
Considerando che gli altri accounts funzionano benissimo e non hanno
problemi, non so più dove sbattere la testa.
Ovviamente asterisk è configurato a dovere per il nat (altrimenti non
funzionerebbe una cippolazza).
Non capisco, soprattutto, se il problema è lato mio o lato provider.
Loro non mi sanno dare una mano.
Thanks.
Max

 (squillo) me lo trovo con la regitration failed.
Ti consiglio di postare qui il tuo problema: 
http://gaming.ngi.it/forum/forumdisplay.php?f=525
Poi, eventualmnete apri un ticket su 
http://assistenza.ngi.it/
-- 
Davide Granzotto 



Grazie.
Avevo comunque già telefonato all'assistenza qualche giorno fa, altrimenti
non avrei postato sul NG.
Vediamo se sul forum riusciamo a risolvere.
Max

> ho un asterisk dietro ad un FW linux che fa nat.
Io avevo un problema simile e ho risolto con la funzione qualify.
http://www.voip-info.org/wiki/view/Asterisk+sip+qualify
-- 
Gangio (
andrea@g_a_n_g_i_n_i.net
)
http://www.gangini.net
Leva gli underscore per mandarmi una mail

 
http://www.voip-info.org/wiki/view/Asterisk+sip+qualify
Grazie.
L'avevo già attivata (yes) che di default è a 2 secondi.
Ora l'ho spostata a 500 ma non credo sia quello il problema.
Il qualify forza una richiesta di options.
Se per qualche arcano motivo a me sonosciuto le risposte la mattina me le
trovo in entrata su una porta molto alta, non sulla 5060, non riescono a
giungere al mio asterisk che la risposta alle options non la vede nemmeno.
Io non capisco perchè la connessione è sempre 5060<->5060 e poi di punto in
bianco, la mattina me la trovo   io 5060 <-> squillo porta >10000.
O il mio Firewall perde il connection tracking sull'UDP, ma dovrebbe farlo
anche per gli altri account, oppure non ho idea.
Tra l'altro forzo pure la direttiva port a 5060.
Mah!
Max

 anche per gli altri account, oppure non ho idea.
Non ho capito una cosa, da che lato esattamente ti arriva la 
connessione a porta alta? Da squillo verso il firewall? Perche` se e` 
cosi` allora e` chiaramente il connection tracking del firewall. No? 
Se invece il firewall manda correttamente il pacchetto indietro verso 
asterisk e asterisk lo rifiuta perche` la porta e` errata allora il 
connection tracking va benissimo e il problema e` da qualche altra 
parte... in questo caso puoi provare con insecure=port nella sezione 
di squillo di sip.conf (vado a memoria, controlla che sia proprio 
quella l'opzione).
Ciao. Marco

 quella l'opzione).
Uso insecure=very.
Mi documento sull'insecure=port.
Thanks
Max

 Mi documento sull'insecure=port.
insecure=port e` un sottoinsieme di very, non ti serve fare questa prova.
Ciao
Marco

 Ora, come ieri, le connessioni sono TUTTE sulle porte 5060 ovvero:
Capitato ora....
tcpdump da asterisk:
17:33:12.071165 IP 10.10.10.3.5060 > 194.185.88.60.5060: UDP, length 378
17:33:13.018215 IP 10.10.10.3.5060 > 194.185.88.60.5060: UDP, length 440
tcpdump sul firewall: (10.10.11.1 è il mio ip pubblico, diciamo)
17:33:12.099090 IP 194.185.88.60.5060 > 10.10.11.1.4672: UDP, length: 502
17:33:13.009605 IP 10.10.11.1.5060 > 194.185.88.60.5060: UDP, length: 440
17:33:13.044956 IP 194.185.88.60.5060 > 10.10.11.1.4672: UDP, length: 423
la conntrack del FW contiene:
udp      17 179 src=10.10.10.3 dst=194.185.88.60 sport=5060 dport=5060
src=194.185.88.60 dst=10.10.11.1 sport=5060 dport=5060 [ASSURED] use=1
Quindi, come accennavo, tutto "dovrebbe" essere sulla 5060.
Ma ad un certo punto le risposte mi tornano su una porta diversa,
randomica...
MAH
MAx

 Poi, eventualmnete apri un ticket su 
http://assistenza.ngi.it/
Ora provo col ticket.
Max

 randomica...
scritto cosi` pare colpa di NGI, ma mi pare evidente che i dati che 
posti sono incompleti. Il primo pacchetto che catturi sul firewall e` 
gia` una risposta di ngi alla 4072 percio` prima ci deve essere stato 
un evento scatenante che ha cambiato la porta.
Tieni presente che linux cerca di utilizzare la stessa porta sorgente 
se sulla macchina che fa il nat quella porta e` libera, se invece e` 
gia` occupata ne usa una random... Quindi se ci fosse - ad esempio - 
una seconda connessione udp che cerca di partire dalla porta 5060 il 
firewall la rimapperebbe su un'altra porta.
C'e` solo quella occorrenza dell'ip di squillo nella tabella di 
conntrack? Non so cosa tu avessi filtrato ma se stavi monitorando l'ip 
di squillo avresti dovuto avere in risposta alla 4072 un icmp di port 
unreachable che non vedo, percio` forse anche quella era una 
connessione valida?
Ciao. Marco

 connessione valida?
Eh si c'č solo quella occorrenza.
L'unreachable non c'č, come risposta.
Casualmente ieri stavo tcpdumpando e ho visto degli icmp unreachable ma
dopo un pň hanno smesso.
Probabile che dopo un pň cominci ad ignorarli e a no rispondere per non
amplificare l'effetto.
Mi rimane il dubbio. Perchč non accade con altri providers ?
Inoltre ... perchč tutto funziona e ad un certo punto non funziona piů ?
Quasi quasi ora mi salvo qualche centinaio di mega di tcpdump per cercare
il punto esatto in cui accade.
Max