Newsgroup: it.tlc.telefonia.voip
Titolo: Tutti giù perterra

Scusate il titolo stupido. Ma ci sta....
 
Su uno dei miei centralini asterisk (ne ho una trentina in giro e nessuno ah questo problema) succede una cosa assai bizzarra.
 
Ogni tanto, in maniera assolutamente random, capita che tutti i dispositivi collegati al centralino si deregistrano.
 
Praticamente se faccio un sip show peers ottengo:
 
Name    Host          Dyn Forcerport ACL Port     Status
401/401 (Unspecified) D   N          0            UNKNOWN
401/402 (Unspecified) D   N          0            UNKNOWN
401/403 (Unspecified) D   N          0            UNKNOWN
401/404 (Unspecified) D   N          0            UNKNOWN
.......
 
Ora, tenete presente che sono 25 telefoni e 4 Patton e TUTTI insieme vanno giù!
Poi pian pianinio, in media ci mettono una decina di minuti, un po' alla volta si ri-registrano.
 
Penserete ad un problema sullo switch sicuramente o alla scheda LAN del centralino. Ma non è così.
Io sono collegato al centralino via ssh, da un pc collegato allo stesso switch, e la mia connessione rimane sepre in piedi, non può essere lo switch, e quindi nemmeno la scheda LAN del centralino. Inoltre, quando questo avviene, io tutti i telefoni, ed anche i Patton, riesco a pingarli dal centralino, tutti quanti!!!!
 
Avete qualche idea? Io brancolo nel buio :-(
 
Grazie 1000.

 Poi pian pianinio, in media ci mettono una decina di minuti, un po' alla volta si ri-registrano.
 
Ipotesi strampalata ma suggestiva:
si aggiorna l'ora di sistema del pc, viene spostata in avanti di
X minuti ed il server, non vedendo arrivare registrazioni da
X minuti, considera gli user agent sloggati. Questi ultimi, non
sapendo cosa accade alle loro spalle, si rifanno vivi alla
spicciolata, alla scadenza naturale della propria registrazione.
 
L'ipotesi è strampalata, perché non penso che il software si basi 
sull'ora assoluta né che i telefoni abbiano un periodo di
registrazione di diversi minuti...però potrebbe ritornare buona
per altri scenari :P
 
Ciao,
 
-- 
Virgilio Lattanzi, TSComm srl


Davvero moooooolto interessante. Ti dico una cosa, su questo centralino ho da tempo impostato il servizio ntp perché guarda caso.... aveva problemi con l'orologio di sistema!!!!
 

Ora la domanda è.... in casi simili, come faccio ad avvertire tutti i dispositivi sip (telefoni e patton) che sono stati disconnessi e che devono ritentare la registrazione? Ho visto che di default hanno tutti un user_expiry di 600 secondi, e non voglio aspettare 10 minuti per le registrazioni, non voglio adesso ripassare la configurazione di 30 apparati. 
 
 

Qualcosa tipo sip notify ....
 

 Qualcosa tipo sip notify ....
 
Il problema è che se asterisk vede il telefono non registrato come fa a mandargli le NOTIFY?

 
 
Pur continuando ad essere scettico sulla mia ipotesi, limiterei i danni
alle ore notturne.
 
L'allineamento del clock fai in modo che accada quando non provoca 
danni, tipo alle 3 di mattino.
 
Ciao e buon lavoro,



Invece ti assicuro che hai fatto centro.
Grazie 1000.

Virgilio Lattanzi wrote on 27/07/17 15:00:

Virgilio, sei il solito genio! ;-)
 
Mi chiedo però come sia possibile che gli orologi dei vari apparati possano 
essere sballati di *minuti* ogni volta?
Specie se il centralino stesso come ha scritto ha il servizio NTP.
 
ciao
Gabriele

 Specie se il centralino stesso come ha scritto ha il servizio NTP.
 
No, solo il server ha dei problemi con il proprio orologio, insieme
ad un algoritmo di funzionamento del sw poco robusto. L'interno 300
si registra alle 8:00:00 con un periodo di 10 minuti. Si rifarà vivo
poco prima delle 8:10:00. Nel frattempo, metti alle 8:05:00, il servizio
NTP (che allinea il clock del server) sposta l'orologio del solo server
in avanti di 15 minuti (8:20:00). La cosa potrebbe anche spostare l'ora
visualizzata dai telefoni sui display, ma è improbabile che il firmware
dei telefoni abbia lo stesso bug del server.
 
Il server controlla l'ora e vede che l'interno 300 che doveva farsi vivo
entro le 8:10:00 è evidentemente spento e lo slogga. Se il salto in
avanti è notevole, fanno tutti la stessa fine.
 
Nessun programmatore sano di mente usa l'ora interna della macchina
per valutare i timeout, proprio per i motivi di cui sopra e perché anche
in condizioni non patologiche i salti di un'ora si verificano nel
passaggio da ora solare a legale e viceversa. Te lo immagini un ospedale
con tutti i telefoni che si sloggano alle 2 dell'ultima domenica di
marzo?
 
Per questo, finché non vedo la riga di codice, continuo a non crederci
e a pensare che l'OP sia solo vittima di autosuggestione :P
 
Ciao,


 Grazie 1000.
 
Prego, ma come direbbe Razzi imitato da Crozza:...mah, io non creto...


Scrivo dal cellulare e non vedo se viene inserito il testo a cui rispondo.
Virgilio Lattanzi dichiara di aver studiato in un Liceo dove l'orologio poteva essere spostato in avanti dallo studente birichino per uscire 5 minuti prima.
Altri tempi, Virgilio!
Adesso, per saltare l'interrogazione o il compito, si preme (ben nascosti  dietro un angolo) il pulsante dell'antincendio che fa partire la sirena.
Bastardi e pure bestie, benché simpatici lo stesso.
 
Alessandro D'Arpini


Non è auto suggestione.
L'ho provato io stesso. Ho cambiato volutamente l'orario portandolo di un'ora avanti e tutti gli apparati bum.... tutti deregistrati, però adesso essendomi fatto il mazzo, ed avendo ripassato la configurazione di 25 telefoni e 4 patton, ed avendogli detto che lo user_expiry è di 60 secondi, ecco che nel giro di un minuto torna tutto apposto.

 L'ho provato io stesso. Ho cambiato volutamente l'orario portandolo di un'ora avanti e tutti gli apparati bum
 
Porca Eva...comunque bravo per l'impeccabile approccio scientifico.



 
Il centralino può fare da server NTP? Se sì, non dovresti avere più quel problema.
Certo che non è tanto normale che l'orologio sballi così tanto e spesso.
 
Gabriele

 
 
infatti o comunque avere dei riferimenti corretti il che mi pare la base 
per qualsiasi discorso in rete....
 


Certo che il centralino può fare da ntp se installi il servizio.
Il problema è un altro, il problema è che il centralino stesso sballa l'orario, e quindi ciò non ha senso.
 
L'orario sballa per un motivo, ho scoperto che il cliente ha problemi di corrente, se ne va la corrente per un po' (più di uanto l'UPS riesce a sopperire) e siccome io i centralini li faccio con il raspberry pi.... che non ha batteria tampone... ecco che quando si riaccende ho la data al 01/01/1970, e siccome se ne è andata la corrente, anche il router si è spento, e siccome il Raspberry è più veloce del router, quando parte, internet non c'è ancora, e il client NTP non riesce a sincronizzare l'orario, quindi parte asterisk, e tutti gli apparati sip si registrano, ma siamo ancora nel gennaio del '70
Ma ecco che arriva internet, il client NTP riaggiusta l'orario, e di colpo asterisk vede che sono passati 47 anni da un notify e l'altro degli apparati, ed allora segna a registro... siete tutti assenti!
Siccome i miei apparati avevano il valore di default sullo user_expiry di 3600 secondi, ecco alcuni telefoni o anche i patton potevano impiegare anche circa un ora per ri-registrarsi.
Adesso ho messo user_expiry = 60 secondi a tutti, così male che va si ripristina tutto velocemente.
Spero che il cliente risolva presto i suoi problemi di corrente elettrica.
Virglio Lattanzi grazie di nuovo!