Problema DECT-IP con BSIP1 su OSOMX

[Gen]

OpenScape Office MX V3 R3.3.0 (002)
Mainboard: Rev. 6.xx (HWID: [0xa1-0x06])
Bios: APO_034 (DATE: 10/01/2010)
MMC: Firmware 5.09

N.2 Antenne BSIP1 entrambe con release: V1-R4.4.0_V3.34.14
N.15 Cordless Gigaset S4 Professional (non conosco la release).

Buongiorno ragazzi,
Ho un problema su una centrale OSO MX (ultima versione) con installati e perfettamente funzionanti 15 telefoni HFA (n.2 OpenStage 40 e n.13 OpenStage 15), installato un modulo 4xS0 con collegate 4 linee ISDN (PP) in ricerca automatico; fino a qui nessun problema.
Ho installato 2 antenne BSIP1 (aggiornate alla versione indicata, l'ultima) di cui una Iwu Master ed una Slave, ci ho registrato (con successo) 15 cordless S4 Professional nuovi.
Mi trovo con questo enorme problema, che accade sia con soltanto 1 antenna, che con 2/3/4 antenne: i cordless si registrano ma spessissimo (mediamente 10 secondi) A RIPOSO perdono la base con indicazione “Nessuna base” per poi riagganciarla poco dopo.
Registrando invece dei telefoni usate SL37H il problema accade comunque ma con minor frequenza (mediamente 1 minuto).
Con qualsiasi cordless se riesco (a base agganciata) a fare una telefonata, una volta in comunicazione non perde né la comunicazione né la base, e girando per tutta l’azienda con il Metering Mode attivo mi rendo conto che fa roaming tra le antenne perfettamente, senza perder la comunicazione, senza problemi di voce e con una ottima qualità; con 4 antenne se passo l’azienda mi aggancia in sequenza tutte le antenne, ma appena riaggancio dopo pochi secondi perde la base (in qualsiasi posizione mi trovi e sotto qualsiasi antenna).
Il problema in questione si verifica nel modo analogo anche con SOLTANTO 1 antenna BSIP1 (Iwu Master).

A qualcuno è capitato ed è riuscito a risolvere?
So che il problema è capitato a più partner e la maggior parte di essi non hanno risolto..

Sono disperato.
Grazie e buon lavoro!!
Gen.

[Kimera]

Ciao Gen,

prima domanda: nella IWU, il campo "MSN" ed "UserName" sono uguali tra loro e corrispondono al numero di interno sotto "User" -> "Voip" ?

seconda domanda: non hai attivato il PTP (IEEE 1588) vero ?

terza domanda: i terminali che si disconnettono vengono presentati come "RAS down" nel menù "Status" -> "CallsDect" -> "Voip states" ?

Saluti, Kimera.

[Gen]

1. Si: MSN, UserName, AuthName corrispondono, e corrispondono all'interno (impostato poi su OSO MX con anche una password per l'autenticazione, e si autenticano tutti subito al volo senza problemi). NOTA: quando invece al posto di "Register" faccio l'"Unregister" faccio molto fatica e non me li deregistra dicendo che non è possibile.. Se insisto un po riesco ma con fatica. Se invece deregistro gli SL37H che sono più stabili al 90% delle volte me lo fa al volo.

2. Non ho idea di cosa sia il PTP (IEEE 1588) quindi presumo di no.

3. I terminali che si disconnettono (e si riagganciano subito) sono praticamente tutti, e MAI nessuno viene presentato come "RAS down" in nessun momento, sempre "RAS up" e "Located on".

Thanks.

[Kimera]

Perfetto, quindi forse il colpevole potrebbe essere il Gigaset S4 Professional...so che è fuori OSO MX V3 R3.4.0...ma prima di andare a vedere l'OSO MX direi che una controllatina ai Gigaset S4 non farebbe male.

Il punto (2) era inteso per capire SE avevi seguito o meno le raccomandazioni per la creazione obbligatoria della VLAN in caso di utilizzo di PTP.

Attualmente per i Gigaset S4 Professional dovrebbe essere disponibile il rilascio V1 R4.2.0 con APS V78.053.05 (anche se questo era disponibile in F.T. a Luglio del 2012...) oppure addirittura qualche cosa di più recente (da verificare): via USB e mediante il tool Gigaset QuickSync (vedi sito gigaset.com), terminale per terminale, dovresti riuscire ad aggiornare (se è necessario) i terminali (in verità c'è anche un tool chiamato Gigaset Firmware Update UI...ma penso che con il Gigaset QuickSync si possa fare lo stesso) e vedere SE questo ha o meno un certo impatto sul problema.

Alla fine, fatta questa verifica, potrebbe anche rivelarsi per quello che forse è: un bel buco della release HiPath Cordless IP V1 R4.4.0 (beh...qualcuno con la stessa tua versione potrebbe anche provare, sia IWU che Server...per vedere SE è effettivamente così oppure SE il problema è relativo invece alla tua specifica configurazione).

Saluti, Kimera.

[Gen]

Premetto che ho avuto problemi simili di "sganciamento" basi anche con una versione precedente alla V1 R4.4.0.. (non ricordo quale).
Detto questo ho provato ad aggiornare l'S4 Professional (attulamente alla 78.053.02) via USB con il software Gigaset QuickSync 7.2.844.6..
Non c'è assolutamente nulla da fare: l'S4 Professional non è supportato e NON lo aggiorna, per di più ho girato su SEBA e sul sito Gigaset ma non trovo il modo di aggiornarlo.
Ho letto anche alcune pagine in tedesco riguardante questo ma non ho trovato soluzione.
Escludo anche un problema di configurazione di HiPath Cordless IP in quanto i settings sono stati controllati/rifatti da un tecnico molto più esperto di me.

Sono shokkato, e non so come muovermi.
E' possibile che sia stata rilasciata una versione che NON funziona? Nemmeno con una sola antenna Master? La configurazione dell'antenna sono davvero pochi passaggi.

[Kimera]

Mi verrebbe da risponderti che "tutto può essere" ma temo non sarebbe una risposta consolatoria...piuttosto per aggiornare il Firmware dell'S4 serve il Gigaset FirmwareUpdate UI V1 R1.1.0 (noto come FWUUI ...un acronimo più idiota non potevano scegliere!) via USB, ce l'hai ? l'hai provato ? ti è riuscito ?

Sulla V1 R4.2.0 del Gigaset S4 Professional hanno corretto (ma non chiedermi lumi in merito perchè è scritto da cani):

CAFT 707 DECT errors (distortions, connection drops) upon high handset concentration at overloaded einstein base stations (<-- non dovrebbe essere però il tuo caso...)
CAFT 711 SL4/[Diamond, RSK] Right soft key functions resets to default after restarting handset. No bearing on Gigaset S4 Professional
CAFT 717 MAC: collision "cx-req" vs. "service-req". No bearing on Gigaset S4 Professional
CAFT 723 DLC: collision "retransmission" & "receive ready". No bearing on Gigaset S4 Professional

Non credo che la V1 R4.4.0 sia così bucata...l'avrebbero rimossa (withdrawn) dal SEBA immediatamente appena se ne fossero resi conto (com'è avvenuto in passato per rilasci di altri prodotti) anche perchè, ormai, è disponibile da due mesi.

Hai semmai provato a (re)installare la V1 R4.4.0 sulla IWU e sulla Slave ? ...una sorta di forzatura ma tentar non nuoce.

Saluti, Kimera.

[Michele]

Ciao Gen,
anche da noi si verificava la stessa cosa (in ufficio abbiamo una sola BSIP1 e con cordless vari, sempre Gigaset SL610Pro, SL4 e S4 e capitava la stessa identica cosa). Ho notato che con l'aggiornamento dell'OSO MX alla V3 R3.4.0 il problema non si è più presentato (o almeno non è più successo finchè ho il cordless a riposo vicino a me).

[Kimera]

Non mi rimane che caldeggiare l'update a OSO MX V3 R3.4.0...anche se, a ben guardare, rispetto alla V3 R3.3.0, sembrano non essere stati corretti bugs relativi (direttamente/indirettamente) a terminali DECT su sistemi HiPath Cordless IP V1...ma si sa come sono le Release Notes (è sempre ben valsa la prova sul campo).

Saluti, Kimera.

[Gen]

Ciao a tutti.

Mi verrebbe da risponderti che "tutto può essere" ma temo non sarebbe una risposta consolatoria...piuttosto per aggiornare il Firmware dell'S4 serve il Gigaset FirmwareUpdate UI V1 R1.1.0 (noto come FWUUI ...un acronimo più idiota non potevano scegliere!) via USB, ce l'hai ? l'hai provato ? ti è riuscito ?

Ho fatto 2 telefonate in Gigaset e nessuno è stato capace di dirmi come aggiornali ("prodotto nuovo" "bla bla bla..").
Per di più è anche diversa la modalità di accesso al Metering Mode, che è uguale sui cordless Gigaset/Siemens da anni ed anni.

Hai semmai provato a (re)installare la V1 R4.4.0 sulla IWU e sulla Slave ? ...una sorta di forzatura ma tentar non nuoce.

Quello l'ho fatto, senza risultati.

Ciao Gen, anche da noi si verificava la stessa cosa (in ufficio abbiamo una sola BSIP1 e con cordless vari, sempre Gigaset SL610Pro, SL4 e S4 e capitava la stessa identica cosa). Ho notato che con l'aggiornamento dell'OSO MX alla V3 R3.4.0 il problema non si è più presentato (o almeno non è più successo finchè ho il cordless a riposo vicino a me).

Purtroppo l'OSO era già alla V3 R3.4.0 in fase di installazione..

Risultato:
Alla fine ho risolto aiutato da Siemens (GSI). Si trattava di alcune piccole imperfezioni di configurazione, e probabilmente un problema di clock "imperfetto" sull'antenna Slave che forniva la sincronizzazione via LAN (Air l'avevo tolta precedentemente).
Mi è stato anche detto che i vecchi cordless S3 ed SL3 sono molto meno sensibili allo sganciamento dell'antenna (vero) mentre altri modelli ed i nuovi S4 sono molto più sensibili..
Ora invece funziona tutto bene e non perde più la base su nessun cordless.

Grazie ragazzi,
Gen.

[Lucky]

Ciao, potresti darci maggiori delucidazioni sulle impostazioni?
per quanto ne so le impostazione su lan (rfc1588) non ha altre impostazioni se non slave o master, il resto sono accorgimenti sulla rete!?!
L' unica cosa che mi viene in mente é il server ntp (stratus 1, 2, 3 ... ma questo dipende da quale serve si utilizza) ma s' imposta sulla master non sulla slave?

L' impianto che abbiamo migrato da poco è da 28(erano 31) antenne e tranne alcuni problemi esterni iniziali sembra tutto regolare, ma magari non mi stanno segnalando i problemi.

[Kimera]

Sarei curioso anch'Io riguardo le "imperfezioni di configurazione" che ti sono state contestate dal GSI (nel senso: sono dei Tips noti solo al GSI che essi applicano agli scenari da loro stessi raccomandati oppure seguendo normalmente la manualistica e tutte le note/raccomandazioni/restrizioni presenti nelle R.N. di OSO/HiPath 3000/Cordless IP si riesce a fare un setup esattamente come lo farebbe il GSI ? ...ovvero un setup funzionante ?).

Se si tratta di Tips noti solo agli sviluppatori o al Supporto Tecnico...beh...sarebbe il caso di renderli "pubblici" in modo che gli installatori/tecnici ne possano beneficiare.

Non ho capito dalla risposta che mi hai dato riguardo il Firmware Update dei Gigaset S4 Professional se sei in possesso (o meno) del FWUUI (vedi SEBA) e, soprattutto, se l'hai provato.

Riguardo l'NTP: sicuramente il Clock (e la sua uniforme distribuzione) hanno MOLTA importanza nelle reti VoIP (LAN)...quindi avere una unica sorgente NTP (pur esterna alla LAN se non si ha un NTP di riferimento interno) per tutti i dispositivi che devono interagire tra loro non può che essere caldamente consigliato (avete mai visto cosa accade ad avere, ad esempio, clients Microsoft non sincronizzati, in termini di Date/Time Clock, con il loro AD controller ?).

Saluti, Kimera.

[Gen]

Ciao,
rispondo a tutti e 2:
per quanto riguarda la sincronizzazione in effetti non c'è molto: la Iwu è impostata come 1588 Slave, come le altre antenne a parte la quarta che è impostata come 1588 Master; come ParkSync in questo caso l'antenna 4 avrà n/a e le altre 3 avranno [004] BSIP1-4. ParkSync 2/3 non sono impostati.

Si è collegato direttamente il GSI sulla Iwu, ma mi han detto che la modifica riguardava soltanto i flag Diversity e Ctr6 (che ad ora sono disattivati anche sulle Slave, mentre mi era stato consigliato di attivarli sulle slave, ed in certi casi anche sulla master).
Server NTP invece ho impostato l'IP locale dell'OSOMX, soltanto sulla Master.

Per quanto riguarda il FWUUI non l'ho provato perchè appena risolto ho ridato il cordless S4 al cliente ed ora non ne ho più: appena ho un attimo di tempo ed un cordless lo scarico e lo provo, dato che potrebbe servirmi (thanks).

Saluti,
Gen.

[Lucky]

Scusa se dubito, ma la documentazione indica chiaramente che il parksync bisogna settarlo solo in condizioni di sincronizzazione "on air"
"ParkSync" (3 columns)
Hint: This option is only functional for BSIP which are synchronized via air (Sync option "air"). For Ethernet synchronized BSIP this option is without function.
Per il flag antenna diversity non metto becco, ma per il ctr6 è sconsigliato vivamente di attivarlo in funzionalità normale.
Per quanto riguarda ntp ti consiglierei comunque di verificarne l' affidabilità (stratus), perchè è vero che i server linux sono più affidabili di altri ma un test è sempre meglio farlo, io ho scaricato da internet un programmino gratuito (ntptool).
 
 
 
 

[Gen]

Grazie il tool per NTP lo proverò sicuramente, non ho mai valutato l'affidabilità.
Il ParkSync1 dovrebbe dirgli anche in caso di LAN da quale antenna una deve prendere la sincronizzazione; me l'hanno comunque verificato loro e mi han detto che è corretto impostato in questo modo.. Io non posso che fidarmi, avendo poca esperienza sulle BSIP1!

Ciao,
Gen.

[Kimera]

Riguardo le configurazioni della parte Radio delle BS (menù DECT -> Radio):

• Diversity: If this option is enabled, the antenna diversity feature for the selected BSIP1 is activated.
• CTR6: This option is exclusively needed for specific tests according CTR6. After activation of this feature, specified test cases may be initiated. This option must not be activated during normal productivity operation of the HPCIP system.

la prima, Diversity, può anche essere attivata (salvo valutare se, ed in che termini, porta del tangibile beneficio) e penso si riferisca logicamente e semplicemente a questo: "The base station works as option with antenna diversity (this means that the radio receiver is connected to whichever antenna delivers the greater field strength)." (ad esempio: basta ricordare come è stato concepito l'Antenna Diversity dei ricevitori FM...tipo quelli per auto ma non solo per quelli...per i quali si montavano due antenne in zone distanti/differenti per captare i differenti segnali radio generati da una stazione trasmittente dovuti al multi-paths: non so quanto valga per due antenne montate così vicino sulla medesima BS ma probabilmente, trattandosi di antenne rice/trasmittenti, la cosa potrebbe avere un certo senso dal punto di vista del terminale DECT ad esse collegato che dovrebbe rilevare l'antenna, tra le due, con il migliore segnale radio o con il migliore Rapporto S/N).

Per la seconda, CTR6, appare evidente come essa sia un Flag da attivare in caso di Debug (Trace ?) utile per lo sviluppo...mentre in un normale sistema di produzione tale Flag va tenuto disabilitato (sia sulla Master che sulle Slaves).

Riguardo l'NTP...allora se l'NTP di riferimento per la BSIP-IWU (Master) è l'OSO MX (che diviene NTP Server per il segmento di LAN di sua competenza)...a sua volta bisogna verificare che esso si connetta ai Pool di NTP Server primari in Internet (un buon punto di riferimento grazie al quale documentarsi sull'importanza di scegliere gli NTP Server più adatti si trova naturalmente qui).

Per il ParkSync (che è valido solo quando il Sync è settato su "Air" ovvero per default): esso non vale quando è attivo il metodo di sincronizzazione IEEE1588 PTP (over Ethernet), come ha giustamente fatto notare Lucky.

Saluti, Kimera.