Get Adobe Flash player
Benvenuto, Ospite
Nome Utente Password: Ricordami

Problemi sul call routing.
(1 Online) (1) Ospite
  • Pagina:
  • 1

ARGOMENTO: Problemi sul call routing.

Problemi sul call routing. 24/02/2012 19:13 #118

  • IK2XYP
  • Offline
  • Amministratore
  • Messaggi: 21
  • Karma: 1
Ciao a tutti,
ne approfitto per aggiornarvi circa l'analisi che sto portando avanti da diverso tempo in ambito di call routing e le relative problematiche sui ponti ripetitori ICOM.
Sebbene lo studio del problema sia ancora in corso, preferisco ribadirlo nuovamente, questo e' un fenomeno che riguarda unicamente gli impianti gestiti dal software ICOM G2.

Coloro che operano in D-STAR via call routing tramite la rete ircDDB ed impiegano dei sistemi ICOM si saranno accorti che molto spesso le informazioni di routing usate dal ripetitore sono sbagliate, con la conseguenza che la chiamata non va a in porto; spesso un lato della comunicazione avviene, ma non l'altro e questo riguarda sempre quando la partenza e' un ponte ICOM.
Per esempio se D1 fosse un ponte ICOM e D2 un ponte home-brew, quello che si e' notato e' che quando qualcuno da D1 chiama in call routing una stazione che dovrebbe essere raggiunta su D2, la comunicazione di D1 viene instradata su qualcosa di diverso da D2 (oppure su un modulo di D2 non corretto), mentre invece quando sara' qualcuno su D2 che chiama, la comunicazione viene sempre instradata correttamente per D1.

La ragione per cui a soffrire di questi problemi sono solo gli impianti ICOM rispetto ai sistemi home-brew dipende dal fatto che quest'ultimi non memorizzano le informazioni di routing, bensi' le ricevono dinamicamente dal network ircDDB; invece un sistema ICOM memorizza queste informazioni in un database interno. Dal momento che il ponte ICOM lavora su ircDDB vi sono dei meccanismi per cui le informazioni ricevute da ircDDB vengono scritte su una tabella secondaria per poi essere copiate anche sulla tabella principale usata dal software ICOM per determinare gli instradamenti in call routing.
Infatti ircDDB e' un software aggiuntivo al sistema ICOM che continuera' ad usare unicamente la tabella preposta al routing (quella primaria); se per qualche motivo la tabella secondaria usata da ircDDB fosse diversa dal contenuto della tabella principale usata dal software ICOM ecco che avremmo il famoso problema di routing.

Lo scopo di questa lunga analisi, svolta in tutto questo tempo, e' stato quello di determinare quali fossero le cause per cui queste due tabelle perdevano il sincronismo e rendevano impossibile eseguire call routing su un impianto ICOM che volesse operare con stazioni attive sui sistemi home-brew.
Dopo varie prove si e' potuto appurare che l'interconnessione del ponte ICOM su un reflector fa innescare molto rapidamente questo problema, in quanto lo scambio dati sul lato Internet tra i vari gateways collegati comporta nel ponte ICOM un'errata interpretazione delle informazioni di routing, con conseguente scrittura di informazioni errate nella tabella primaria; infatti controllando la tabella secondaria si continuavano a leggere le informazioni di routing corrette.
Non appena il Gateway si scollega dal reflector e riceve gli aggiornamenti dalla rete USTRUST e ircDDB ecco che le due tabelle ripristinano il sincronismo iniziale.
Analizzando il funzionamento del network ircDDB esso e' molto piu' efficiente nel fornire le informazioni di routing che vengono inviate ai vari sistemi D-STAR collegati al server centrale mediante un'operazione di tipo "push", ovvero e' il server che invia l'informazione appena vi e' stato un cambiamento nel routing per ogni stazione.
Invece il sistema ICOM che sfrutta il Trust Server per il sincronismo del database e' molto piu' lento a recepire gli aggiornamenti, dal momento che le interrogazioni avvengono ogni 5 minuti.

Un primo rimedio molto semplice che ho potuto testare e che risolve queste problematiche consiste nel far aggiornare le tabelle di routing tramite ircDDB da parte della persona con cui vorremmo parlare.
Supponendo che la stazione XXX volesse parlare con YYY e quest'ultimo fosse sul ponte ICOM D1 (mentre XXX fosse su ponte home-brew D2), qualora D1 non conoscesse la rotta giusta per far parlare YYY con XXX, basterebbe che XXX commutasse su un altro sistema ircDDB e trasmettesse brevemente in modo da innescare un cambiamento di routing per poi ritornare nuovamente ad operare su D2.
Questo passaggio comporterebbe che il ponte ICOM D1 recepisca che XXX sia attivo su D2 affinche' il ponte ICOM possa instradare correttamente verso il modulo e ripetitore corretti.
Infatti ogni volta che c'e' un cambiamento nelle informazioni di routing, l'applicativo ircDDB procede all'aggiornamento simultaneo delle due tabelle (primaria e secondaria) sul ponte ICOM restituendogli cosi' le informazioni corrette su come raggiungere la stazione voluta.

Ovviamente questo problema non colpisce i sistemi ICOM quando viene instradata la chiamata direttamente sul ripetitore remoto, ovvero quando si usa il campo UR=/ripetitore_remoto; in questo caso il routing funziona in quanto il ponte di destinazione viene comunque conosciuto, senza che l'informazione in tabella principale sia corrotta.

Un'altra soluzione al problema consisterebbe nel far in modo che il server ircDDB mandi periodicamente la notifica in "push" verso la rete dei sistemi collegati per le stazioni che non trasmettono da diverso tempo e che quindi non hanno avuto modo di far rinfrescare la tabella primaria del loro database.
Questa soluzione comunque e' al vaglio con gli autori tedeschi di ircDDB, per cui nel frattempo e' buona cosa rendersi conto del perche' avvengano questi problemi sulle chiamate in call routing; la cosa positiva e' che il traffico in call routing svolto su STARnet non subisce questo problema, in quanto i server STARnet pubblicano via ircDDB le info di routing periodicamente e pertanto risolvono questo problema gia' sul nascere.
Infatti chi usa regolarmente STARnet si sara' reso conto che il traffico in routing avviene sempre, cosa non sempre vera quando invece si chiama la singola stazione direttamente.

A titolo di analisi ho attivato uno script sul mio gateway ICOM che estrae le informazioni sulle rotte errate viste dal mio sistema; in questo modo ho la possibilita' di verificare quali instradamenti risulterebbero difficoltosi nel mio sistema.
Il file di report viene generato ogni minuto ed e' aggiornato su questo link: ir2ufh.ods.org/bad_routes.txt

Controllando la lunga lista potrete trovare solo quei nominativi che transitano attraverso ponti ripetitori Italiani ICOM e home-brew che utilizzano ircDDB, in modo che la lista sia ridotta all'Italia.
Una certa parte dei nominativi presenti nella lista sono relativi a stazioni che normalmente usano il DVDongle, DVAP o altri sistemi che non fanno giungere il segnale direttamene via RF attraverso un Gateway ircDDB; in quel caso le informazioni di routing sono per forza errate e non vi sono rimedi, dal momento che tali stazioni non possono operare in call routing e quindi non inviano alcune info di routing.
Cio' su cui porre l'attenzione sono quei terminali (quindi nominativo e lettera identificativa all'ottavo posto) che normalmente vengono usati via RF attraverso dei Gateway ircDDB; qualora fossero listati in tabella vorrebbe dire che per essi si e' generata un'incongruenza che non permetterebbe al mio sistema ICOM (e analogamente su molti altri Gateway ICOM) di fare call routing in modo corretto.
La tabella mostra il target_cs, ovvero il terminale di destinazione della chiamata, e le informazioni circa il ripetitore (colonna arearp_cs) che l'impianto ICOM userebbe (nel raggruppamento definito ICOM) rispetto alle informazioni conosciute dal network ircDDB; basta confrontare le due colonne del campo arearp_cs per vedere la differenza di routing.

Bene questo e' tutto per ora, quest'analisi ha permesso di descrivere e dettagliare il problema, fornendo anche un semplice strumento di verifica per capire se la vostra stazione potra' essere chiamata in call routing da un ponte ICOM; se vedeste il vostro nominativo in lista ed avete a disposizione un paio di sistemi ircDDB, vi bastera' trasmettere un attimo sul sistema alternativo per poi ritornare al vostro sistema ircDDB principale. Dopo il minuto dell'aggiornamento della pagina potreste vedere l'informazione corretta ed il vostro nominativo sparirebbe dalla lista.

73's de Armando, IK2XYP.

Re: Problemi sul call routing. 09/01/2019 19:04 #461

  • lupingping33
  • Offline
  • Studente del Dstar
  • Messaggi: 40
  • Karma: 0
  • Pagina:
  • 1
Tempo generazione pagina: 0.36 secondi

Accedi

Accedi al portale per interagire con la comunità!

Chiacchiere

Accendi Spegni Suono Emoticon Storia FAQ Kide Chat
13:04-- ik7lve: Buon pomeriggio a tutti !
15:25-- IZ0ROM: Buona serata a tutti
10:01-- is0aaj-p: ciao a tutti ,appena registrato
21:20-- IZ6OUF: IZ6OUF Comunico la nuova Frequenza del mio Nodo : 430.900 Modo: Simplex Shift: + Freq. Shift: 0. 73 da iz6ouf.
13:41-- IU5FTX: CIAO A TUTTI DALLA PROVINCIA DI FIRENZE
20:40-- IW8ELN: 03-12-2016 Buona Serata a tutti da Roberto. Real-Time DashBoard REF027A attiva all'indirizzo http://xref.homepc.it
20:41-- IW8ELN: A presto
21:40-- IW8ELN: Cliccate su Web Monitor
18:09-- iz7djv: Buon Anno
17:07-- IZ1KGY: uellah, buonasera a tutti
23:44-- IU5IBO: salve a tutti.
22:05-- IU5IBO: Salve a tutti.
20:14-- IU8EOF: Buonasera da IU8EOF
22:35-- IZ6OUF: IZ6OUF COMUNICO IL MIO HOTSPOT E' MOMENTANEAMENTE IN OFF. PER MANUTENZIONE. 73...
21:37-- iw7ed: salve perchè il mio hotspot non risulta nella lista Nodi ?
23:33-- IZ6OUF: TORNATO OPERATIVO IL MIO NODO IN DSTAR. CON I SEGUENTI ORARI: ( INFO NEWS ORARI:) DAL 10/04/17 I MIEI NODI SARANNO OPERATIVI DALLE ORE: DAL LUNEDI AL VENERDI: 20.30-24.00 SABATO E DOMENICA 07.00-24.00
16:52-- IU4HNI: buonasera a tutti
16:57-- IU4HNI: se qualche collega puo aiutarmi per settare un hotspotSharkRF grazie
8:48-- IU2IZX: Ciao, qualcuno può darmi una mano per la registrazione d-star???
19:12-- iw7ed: salve ho inviato una email per informazione......non ho ricevuta nessuna risposta !!!!!!!!!!!!! :(
0:49-- IU4KBA: ciao a tutti
12:43-- IU1HHP: Qui mi sa che nessuno risponde se non un risponditore automatico. Ho chiesto registrazione ricevuto ok ma non risulto. In meno di 15 minuti trust usa mi ha risposto cosi
12:44-- IU1HHP: IRCDDB is NOT part of the US trust and we do no integrate with it. You still need to register your call sign with a trusted D-STAR gateway.Da Trust USA "
19:14-- IZ0ZWR: Un cordiale saluto a tutti Ho fatto la registrazione un po di tempo fà, ma non ho avuto più notizia!! chi può aiutarmi a fare una verifica ??? de IZ0ZWR Fausto
19:37-- IK7XTA: buona sera
16:07-- ik7lve: Un cordiale saluto a tutti. DE IK7LVE.
17:26-- IK2ISX: Chi usa il DV Dongle ? Ci sono nuove funzioni/software ?
20:26-- IU1IMH: 73 a tutti anche da parte mia! Alberto
23:15-- IZ6OUF: SALVE A TUTTI COMUNI INFO SUL MIO NODO OPERATIVO H24. INFO SU:
23:15-- IZ6OUF: https://www.qrz.com/db/IZ6OUF
22:01-- iv3upe: Buonasera Comunico che il Ponte IR3UBK non è attivo da Oggi fino al 01/02/2018 per Manutenzione Rete Elettrica.Saluti IV3UPE.Cristian.
12:02-- iv3upe: Buongiorno il Ponte IR3UBK è di nuovo operativo.73 IV3UPE Cristian.Grazie.
20:42-- ik1mlb: Buona sera a tutti, sono ik1mlb Raoul da Moncalieri( Torino). Ci sarebbe qualcuno nelle vicinanze, che potrebbe aiutarmi via radio, per impostare la radio in D-star?
7:02-- iu0cml: b.giorno a tutti volevo sPERE COME Faccio a recuperare il mio id che nn ricordo?
14:32-- iz7djv: Ben ritrovati,Saluti de Tony
11:48-- IW2NBW: 73 a tutti

Soltanto gli utenti registrati possono inviare messaggi, Registrati o Login