OpenPath
OpenScape => OpenScape - Mobility (HiPath Wireless, HiPath MobileConnect, IP DECT) => Topic started by: Michele on March 05, 2013, 09:34:51 am
-
Ciao a tutti,
non apro un ulteriore topic per i famosi dect openstage sl4 professional, ma mi allaccio a questo.
Ho installato un server con 15 antenne BSIP1, ho collegato una 30a di dect di varie tipologie (sl37h, c59 e sl4 professional). I primi 2 erano già presenti nell'azienda, mentre la serie professional l'abbiamo venduta noi. Devo chiedervi un paio di cose, visto che non riesco a capire come proseguire:
- la fonia nella serie da noi fornita si sente veramente male, ho controllato il firmware ed è 81.999.99. Ho scaricato il tool di siemens, ma al suo interno non c'è nessun altro firmware, quindi dove posso reperirlo?
- questo sistema dect è collegato ad un OSO LX, come posso fare per utilizzare dai dect la selezione breve del sistema (*7xxx) visto che i codici con * e # non sono contemplati nei dect? Posso ovviare in qualche modo con LCR (premetto che ho provato una serie di combinazioni, ma senza risultato)
Grazie
-
Rispondo parzialmente perchè quel 81.999.99 (Software Variant.Software Version.Revision) mi suona davvero strano.
L'ultima versione OpenStage SL4 professional rilasciata è la V1 R1.5.0 (in Field Trial al 05/02/2013) ed ha Firmware marcato V81.053.06 e risolve: "Sporadisch keine Sprachübertragung in beide Richtungen bei der HiPath Cordless IP mit SL4" che tradotto fa (più o meno): "Sporadic no voice in both directions at/between HiPath Cordless IP and/with SL4" che è la stessa frase che appare nel rilascio OpenStage S4 professional V1 R4.3.0.
Quindi il Firmware Update Tool (Build 3568) non contiene nulla ? ...può anche darsi che il Firmware sia da richiedere e pagare (non è detto che la richiesta sia cioè a costo nullo...) perchè altrimenti non mi spiego la frase "Upgrade with costs." che è presente assieme a tutti i rilasci annunciati in SEBA. Qualcuno potrebbe contattare il PM per gli OpenStage SL ?
Saluti, Kimera.
P.S. che versione hai di OSO LX (tra l'altro: come vanno l'uso della CPU e della RAM in normali condizioni di funzionamento?) e HiPath Cordless IP ?
-
Ciao Kimera,
confermo che il Firmware Update Tool non contiene nessun firmware (ho fatto la procedura di installazione dei driver, ha trovato il telefono, vado a selezionare il firmware nella cartella dove ho estratto il Tool, ma non trova nulla).
Come versione di OSO Lx e Mx (gateway) ho la V3 R3.4, le 2 CPU della macchina virtuale si aggirano tra il 15% e 50%, ho 2G di ram, ne usa 1,1G costantemente.
-
OK mi sono permesso di chiedere lumi su in Germania su un Forum tedesco (magari loro sanno qualche cosa in più riguardo la reperibilità dei Firmware per i Gigaset S/SL e/o per gli OpenStage S/SL): ho come l'impressione che ci si debba registrare sul sito Gigaset (vedi qui (http://gigaset.com/pro/it/it/cms/ProPageCategoryPartnerLogin.html)) anche se non ne sono sicuro al 100% (attendiamo) anche perchè Gigaset e SEN sembrano quasi due parrocchie diverse (nonostante da anni vadano procrastinando sulla differenza dei Gigaset consumer e quelli professional...non vedo tradotto questo "sforzo" per distinguere tali famiglie se poi SIEMENS stessa non rilascia chiaramente gli strumenti per la gestione dei Gigaset serie professional).
Per l'LX chiedevo perchè ho letto che si sono riscontrati casi di alto utilizzo CPU per assenza di un parametro da settare a livello Kernel (Bootloader) "hpet=disable" che sistemerebbe la cosa anche se, in questo caso, non penso abbia rilevanza specifica con problema manifestato dagli OpenStage SL4 professional (anzi...il contrario...eventualmente sarebbe una problematica generale del sistema). Quel che mi suona anomalo è quel Firmware marcato 81.999.99.
Vediamo che/se dicono qualche cosa.
Saluti, Kimera.
P.S.
Mi sorge un dubbio: Non è forse che l'Update avviene On-Line attraverso QuickSync ? vedi qui (https://gigaset.atlassian.net/wiki/display/GPPPO/Recommended+Gigaset+PRO+firmware-versions) e poi qui (http://gigaset.com/de/de/cms/PageQuickSync.html).
-
avevo già provato il quick synk, ma non mi presenta nessun aggiornamento nuovo.
Grazie dell'aiuto, sei sempre puntuale!
PS: per curiosità la modifica che citavi ("hpet=disable") dove andrebbe effettuata? All'interno di qualche parametro del server Virtuale?
-
Nella riga del Boot Loader (nel file /boot/grub.conf, se usi GRUB come Boot Loader...) dove carichi il Kernel corrente.
Edit 06/03/2013: sembra che l'inconveniente degli alti carichi della CPU (costantemente sopra il 50% in media) si sia manifestato su OSO LX V3 R3.4.1 (007) implementato su macchina virtuale (2 cores), comunque pare abbia a che vedere con SuSE Linux Enterprise Server 11.
-
Quindi nè l'applicativo Firmware Update Tool nè il QuickSync hanno a corredo (o si connettono On-Line) il nuovo Firmware. OK, direi di stare a vedere se i tedeschi hanno la grazia di rispondere.
-
Ciao,
sono riuscito ad avere i 2 firmware direttamente da Itancia (V1 R1.4.0 e V1 R1.5.0). Ho effettuato l'aggiornamento del secondo, essendo teoricamente quello migliore, solo che il tool di Siemens mi riporta:
"UpdateStatus = (0)(Update is not required.), data[req:0, avail:7209062]
Handset switch back to server mode.
Firmware Update Finished! 224658ms
Handset's Firmware: 81.053.06
Finished!"
A questo punto mi posso aspettare di avere il firmware 51.053.06 (come citato sopra), però mi aspetto anche di averlo invariato visto che mi riporta "Update is not required", ed in effetti facendo il solito codice (menù -> *#06#) il firmware è 81.999.99.
Ma.....misteri....
-
Interessante. Hai provato, ad update avvenuto (anche se riporta quella stringa 81.999.99 alquanto anomala), a fare un reset/factory default del terminale stesso?
Dovrebbe essere: tenere premuti 1+4+7+Tasto On per l'accensione (in contemporanea) fino all'apparizione dell'indicazione "Service" poi digitare 4685463 per il "fundamental reset"...
Hai già avuto modo di testare il terminale così aggiornato (magari sia prima che dopo il reset/factory default)?
Sarebbe inoltre interessante anche sapere come (e da dove) Itancia abbia ottenuto tali Firmware visto che su SEBA non vi è proprio traccia degli stessi (e tu potresti renderli a loro volta disponibili a futura memoria...).
Saluti, Kimera.
-
ciao, ho provato ad effettuare la prova da te richiesta ma nulla di nuovo.
Inoltre continuo a notare che il dect va in ricerca base per 5-6 secondi e dopo si riaggancia.
Il firmware arriva direttamente dalla sede di Itancia in Francia...
-
Che versione del Firmware Upload Tool hai utilizzato per fare l'upload del Firmware ? Itancia cosa dice ?
Questo è un mistero come la scomparsa del Blu di Francia...tanto per rimanere da quelle parti.
-
il tool che utilizzo è l'unico che trovo in SEBA.
Itancia mi dice che per il problema dello sgancio dalla base per una 10 di secondi, siemens dice di togliere tutti i flag da "diversity" e "ctr6", come indicato anche da GEN nel topic già aperto (http://openpath.telmekom.com/index.php/topic,1245.0.html).
Sebbene abbia configurato il sistema dect nella maniera indicata, utilizzi una rete che implementa il protocollo IEEE 1588 come da richiesta siemens ( cito la voce riportata nel wiki di siemens "every 24-port PoE Layer2 switch from Hewlett Packard (HP ProCurve Series), If the customer use Layer3 switches, the L3 function of the relevant switch ports have to be deactivated"), quindi sto utilizzando switch L2 HP, il problema della disconnessione mi capita molto spesso, e fatalità solo con i cordless SL4.
Itancia mi diceva che la Modalità Echo che è attiva nell'ultima generazione di cordless deve essere tolta in quanto causa problemi. Nella serie Professional non l'ho trovata. Sinceramente non so più che prove effettuare.
-
Calma...anzitutto se implementi il PTP (IEEE 1588) non è (quasi) importante il tipo di switch (purchè L2 e non L3) MA è invece obbligatorio creare una VLAN per la rete DECT-IP...ed è pure da richiedere una PSR a Siemens per la corretta implementazione del protocollo...mi pare che queste siano le raccomandazioni da parte di Siemens SE intendi usare il PTP, detta in altri termini:
"Ethernet synchronisation IEEE 1588: Usage of VLAN at the BSIP-IWU for Infrastructure and DECT network is mandatory. All participating switches have to be configured in a way that the VLAN of the DECT network has to be assigned the highest priority"
da HiPath Cordless IP Administrator Documentation Chapter 4.3.
Riguardo agli Echo Settings (DECT)...ho come l'impressione che si riferiscano però all'implementazione del sistema DECT utilizzando CMI/Cordless Office su HiPath 3000 (vedi infatti menu HiPath 3000 Manager E - Cordless CMI - Echo Handling)...a meno che gli stessi parametri non ci siano anche nella parte HiPath Cordless IP, ovvero sembra che disattivare (soprattutto con gli OpenStage S4/SL4 professional) questi parametri: ES (Echo Suppressor), EC (Echo Canceller), AE (Artifical Echo) e DC ...porti a dei benefici. Ripeto...non so se questo suggerimento sia estensibile ad HiPath Cordless IP (lato BSIP o IWU). Dovrei controllare.
HiPath Cordless IP V1 a che release è?
Saluti, Kimera.
-
Ho installato una V1 R4.4.0
-
La V1 R4.5.0, pur essendo di due mesi abbondanti più recente rispetto alla V1 R4.4.0, non sembra apportare alcun bugfix che si possa ricondurre a problemi sulla qualità del segnale radio o agli OpenStage S4/SL4: aggiornare potrebbe essere utile solo per "precauzione" in relazione all'apertura di uno o più Ticket al GVS.
i flags VAD (Voice Activity Detection), Echo Cancellation e Packet Sizes (per i vari CoDecs) come sono configurati lato gateway (MX)?
-
ciao Kimera,
posso dirti che, per precauzione appunto, ho aggiornato il sistema dect all'ultima release, ho aperto un ticket in siemens ma non ho ricevuto ancora nessuna risposta in merito.
I codect sono stati impostati in egual maniera su OSO LX e OSO MX,P, cioè G729A - G711A - G711U - G729AB, senza VAD, packet size 20 ms.
-
Ciao Michele, nessuna risposta nemmeno dai "colleghi" tedeschi...forse non amano i post in lingua inglese (mi auto-domando: ...ma come? ...non lo sapevi? ...e come se lo so!). Ci vuole un pò di pazienza...diciamo che SE (e ripeto: SE...visto che per descrivere tutta la configurazione ci vorrebbero parecchi Screenshots specifici e questi non sempre si ha voglia/tempo/intenzione di prepararli...) tutte le configurazioni sono corrette (quindi sono state eseguite seguendo le varie indicazioni più o meno note e più o meno sparpagliate nelle varie Release Notes dei prodotti coinvolti in questo scenario) non mi rimane che pensare ad un Bug con imputato l'SL4 o, alla peggio, HiPath Cordless IP V1 (a proposito: le BSIP che Prodcut Number esatto hanno?)...
Itancia che dice? ...ci vorrebbe l'aggancio di qualcuno in Siemens che sia responsabile degli OpenStage S4/SL4 professional. Mah. Mi sembra sempre di più tutto un "Terno al lotto".
-
Itancia è nella stessa nostra posizione, non ha notizie nemmeno dalla casa madre.
Comunque la soluzione era installare il sistema di Gigaset, più stabile secondo loro e senza problematiche. L'unica cosa che manca è la rubrica centralizzata, e tutti i servizi che già mancano nel sistema di siemens (la possibilità di utilizzare i codici funzione, tipo *7 per i numeri brevi che sicuramente risolverebbe un po' di problemi).
-
Beh...se Itancia intende mettere sulla bilancia HiPath Cordless Office/CMI da una parte ed HiPath Cordless IP dall'altra (se ho capito bene...) fa un errore...perchè sarebbe come misurare un kg di Mele con un kg di Pere...sempre frutta si misura...ma sopra i due piatti della bilancia ci sono effettivamente frutti diversi (AKA implementazioni diverse di tecnologie simili) e per di più non si tiene conto che molto spesso si è forzati dai componenti in gioco ad andare verso una implementazione piuttosto che verso un'altra (HiPath Cordless IP in questo caso...ma potrei sbagliarmi).
Quindi non vedo la materia del contendere...sicuramente Siemens deve sistemare le cose...ci sono troppi punti "poco chiari" nell'implementazione delle sue tecnologie di punta, soprattutto quando a comporle sono tanti prodotti/applicazioni distinti che vanno fatti "cooperare". Opinione personale, ovviamente.
Poi, non so se l'hai notato, manca sempre qualche cosa...qualche dettaglio/funzione desiderabile...sembra che il nuovo abbia, da un lato, proprietà uniche (tipiche dell'approccio IP) mentre, dall'altro, perda cose ormai date per scontate. Non sono sempre passi avanti.
Saluti, Kimera.
-
Tra qualche giorno dovrebbe essere rilasciato il nuovo Gigaset FirmWare Update User Interface (FWUUI) tool V1 R2.0.0 che, ed è esplicitamente scritto, non contiene alcun Loadware/Firmware per i terminali Gigaset/OpenStage professional.
-
Tra qualche giorno è previsto il rilascio di HiPath Cordless IP V1 R4.6.0 (sia IWU che Server). Non è ancora disponibile la Release Note.
Saluti, Kimera.
-
Grazie Kimera!
-
Di che? ahimè...dal Forum Tedesco nessuna risposta (puoi controllare quanto ho scritto qui (http://hipath.userboard.org/endgerate-f26/openstage-sl4-professional-where-look-for-new-firmware-t1359.html)) nonostante l'argomento sia stato quantomeno letto.
Saluti, Kimera.
-
Tra qualche giorno dovrebbe essere rilasciato il nuovo Gigaset FirmWare Update User Interface (FWUUI) tool V1 R2.0.0 che, ed è esplicitamente scritto, non contiene alcun Loadware/Firmware per i terminali Gigaset/OpenStage professional.
Rilasciato oggi 03.04.2013.
Nota: Gigaset Firmware Update Tool (FWUUI) V1 R2.0.0 (Build V0.1.4654.25635) "This update tool doesn't contain any Firmeware/Loadware for the Gigaset phone."
Aggiunto supporto per OpenStage M3 professional (maggiori informazioni sia nella Release Note che nel Change-Log interno nel quale sono indicate tutte le modifiche, Build per Build).
Saluti, Kimera.
P.S.
A questo punto chiedo ufficialmente: questo benedetto Firmware per i terminali Gigaset della serie professional DOVE ed in CHE MODO è disponibile SE in SEBA non c'è?
-
Ciao Kimera,
visto e sperimentato! questo tool, volendo, si arrangia a scaricarsi il firmware da internet. Controllando lo script che viene visualizzato dal tool, ho notato che il firmware viene scaricato dal seguente indirizzo:
http://update.gigaset.net/firmware/diamond_hs/diamond_2__upd.bin
L'ho scaricato anch'io per prova e il link è funzionante.
Comunque il software è sempre lo stesso: 81.053.06.
Saluti
Michele
-
Infatti, nel Change-Log è indicato che dalla Build 4167 è presente l'opzione di scaricamento del Firmware tramite Internet:
=== 0_1_4654
big change in UI flow: NVM management for GAM3 added
=== 0_1_4616
more data logged to log file
added possibility to upload binary with bad CRC
=== 0_1_4609
if c:\temp folder exists the log file from fwu is stored there
=== 0_1_4469
FirmwareUpdate procedure is updated to the state like in GQS (no error messege)
=== 0_1_4456
*** fix:
version number parsing for borneo
=== 0_1_4427
*** changes:
support of x64 platform (change targer platform build of exe to x32)
However, application reports "*** ERRR: Unexpected connection lost!" - this do not influent update procedure.
Refactor needed to use Handset Updater class.
=== 0_1_4176
*** changes:
New UI skin, new icon, new 'about'
=== 0_1_4167_28177
*** changes: "Autoload from internet" - option added
=== 0_1_4148_25073
*** changes:
BRB support (during FWU handset notifies time needed for update; first time used with Lion ?BL16
=== 0_1_4112_29753
*** changes:
this is trace version; with binary map progress
Lion FWU support
=== 0_1_3568
*** changes:
binary map progress no longer visible
message box on success finish
progress promoted to 100% in case of finish
reconnection improvement on cable disconnect-connect
(please notice that reconnection can take about 90 second
(tested on Gold handset 25.03, connection broken about 25% of emergency update))
-
Update qui (http://hipath.userboard.org/endgerate-f26/openstage-sl4-professional-where-look-for-new-firmware-t1359.html) (per i Firmware): sono troppo pigro per riscrivere tutto.
Saluti, Kimera.
P.S.
Per chiudere completamente il cerchio sarebbe bello sapere com'è andata a finire (o come stà andando...se il tutto è in corso d'opera)!
-
Semplice Kimera...dopo aver aperto il ticket in Siemens, dopo aver ricevuto una risposta incomprensibile, abbiamo sollecitato direttamente gli alti dirigenti di Siemens Italia, entro fine settimana dovrebbero collegarsi e poi vediamo....
Ti tengo sicuramente aggiornato.
-
ciao kimera, dove michele dice:"...Comunque la soluzione era installare il sistema di Gigaset, più stabile secondo loro e senza problematiche ..." , parla del dect-ip di gigaset (non ricordo bene il nome ma contiene un 720) al massimo 20 antenne.
Lo so perchè l' hanno suggerito anche ad un mio collega.
Da un mio cliente ho verificato la scarsità di campo degli sl610pro (versione 81.999.99) rispetto a dei e49h. Purtroppo anche se meglio dei 610, il campo degli sl3 professional é inferiore a quello del e49h, che tristezza.
Modifica: Il dect ip di Gigaset si chiama N720 dect IP: http://gigaset.com/pro/it/it/product/GIGASETN720DECTIPPRO.html (http://gigaset.com/pro/it/it/product/GIGASETN720DECTIPPRO.html)
-
Anch'Io (ma solo per attimo...) ho pensato a quel (https://gigaset.com/pro/it/it/pages/index.html) sistema (Gigaset Pro N720 DECT IP Multi-Cella in particolare)...ma il pensiero se ne è andato nel momento stesso in cui è venuto perchè, visto il contesto della conversazione in corso, davo per scontato che si volesse rimanere nel terreno dei sistemi DECT adottabili con i sistemi HiPath 3000 (vedi: HiPath Cordless IP, DECT CMI, DECT Cordless Office) oppure con OpenScape Office (vedi: HiPath Cordless IP)...e non si finisse (addirittura su consiglio Siemens!) a parlare invece di un sistema di comunicazione costruito (solo/in modo specifico) attorno ai terminali DECT e che nulla (a quanto ne so Io) ha a che vedere con i sistemi suddetti (in termini di collegabilità...ma su quest'aspetto...potrei anche ignorare il fatto che invece collegabili lo sono).
Evidentemente in Siemens (sono loro no che hanno tirato fuori la cosa "contro" lo scenario HiPath Cordless IP no?) non hanno le idee chiare...oppure invece ce le hanno...tanto gli fa di parlare di soluzioni del portfolio HiPath/OpenScape Office quanto di soluzioni provenienti dal portfolio Gigaset Pro (nota che l'utenza potrebbe anche essere la stessa ed avere le stesse necessità...ma ci sarebbe un evidente "conflitto di interessi", vendo Siemens HiPath o Gigaset Pro?).
Quindi capisco la tua precisazione...solo, se così è, non mi sarei aspettato che a introdurre nel discorso i sistemi Gigaset Pro fosse proprio il supporto tecnico (GVS) che dovrebbe esistere per risolvere un problema inerente ben altri sistemi. O sbaglio?
O.T.: per rifarmi a quanto scritto sopra...se da una parte ignoro come (e se) un sistema Gigaset Pro sia collegabile ai sistemi HiPath/OpenScape Office dall'altra sono intimamente convinto che la recente introduzione di tali sistemi (e notate che sono Asterisk based! guardate bene...con Schede PCI delle Digium con Firmware custom-made per Gigaset!) come il Gigaset T500 PRO o il Gigaset T300 PRO (vedi qui (https://gigaset.atlassian.net/wiki/display/GPPPO/Products)) sia (sarebbe/sarà) letale per il mercato già in crisi (ditemi quello che volete...) dei sistemi per i quali siamo abituati a discutere (anche solo considerando la complessità implemetativa di questi ultimi rispetto a soluzioni più piccole e forse meno complesse).
Quindi in sintesi: se avessi una PMI da servire per la parte di telefonia, sapendo tutto quello che so, probabilmente proporrei i secondi e non i primi (non è detto che tutte le funzionalità di OSO siano interessanti per un cliente di una PMI!) e, aggiungo, soprattutto quando ci sono di mezzo terminali DECT la cui copertura radio è più importante delle prestazioni della telefonia fissa.
Penso anche che in termini economici (anche se non ho tutti i dati per fare un confronto A contro B) sarebbe una bella battaglia (forse persa in partenza per le accoppiate HiPath+Cordless IP o HiPath+DECT CMI/Cordless Office) contro i Gigaset T500/T300 PRO. Potremmo aprire un bel Topic a parte, sicuramente desterebbe l'interesse di qualcuno.
Saluti, Kimera.
-
Ho visto il tuo edit...infatti...siamo sulla stessa lunghezza d'onda (sono quelli!).
In merito alle differenze di prestazioni "Radio" dei vari terminali non so come pronunciarmi...secondo me non è chiaro (il perchè) nemmeno a chi li produce...finchè qualcuno non si prenderà la briga di condurre dei Test in un ambiente controllato e in modo da valutare le prestazioni in modo obiettivo usandoli connessi ai vari sistemi che li supportano (lasciando stare le differenze tra DECT e GAP ma solo vedendo se, come e perchè un terminale X si comporta in modo non omogeneo quando è registrato su sistemi DECT differenti per architettura).
Saluti, Kimera.
Edit n°1: anche in Germania qualcuno continua a porsi domande di vario genere (compatibilità con/prestazioni di) riguardo i terminali DECT Gigaset di ieri e di oggi (OpenStage S/SL), vedi, ad esempio, qui (http://hipath.userboard.org/hipath-3000-5000-openscape-business-f20/kompatibilitat-openstage-sl4-pro-sl610h-r410h-t1269.html) (in questo caso specifico ad essere messa in discussione è l'annosa questione dei terminali Gigaset che registrati su sistemi post V8 R4 non sono più visti come DECT - Comfort - ma vengono visti solo come GAP perdendo quelle funzionalità che con le versioni precedenti dell'HiPath 3000 avevano in modo ormai dato per scontato senza limitazioni di sorta). Quindi la situazione è (ancora) tutt'altro che chiara.
Edit n°2: sempre il Germania sembra stiano affrontando i medesimi discorsi (HiPath Cordless IP versus Gigaset PRO), vedete qui (http://hipath.userboard.org/hipath-3000-5000-openscape-business-f20/cordless-hip3k-t1445.html) (verso il nono scambio di opinioni...). Io non so il tedesco...ma con un traduttore il senso si capisce perfettamente (lamentele riguardo la "sprachqualitat"...e qualcuno che profetizza futuri miglioramenti in HiPath Cordless IP come ce ne furono con l'implementazione CorNet IP Trunking SIP di Siemens ai suoi albori sperando dunque che, con il tempo, le cose vadano migliorando...salvo trovarsi poi la risposta di qualcun altro il quale fa notare da quanto tempo HiPath Cordless è in produzione...della serie: a questo punto le cose stanno così e difficilmente cambieranno).
-
Siemens sta controllando, intanto ha detto che la configurazione di LX è giusta.
I giorni passano e il cliente è incazzato.
Sebbene abbiamo una rete distinta per il sistema dect formata da switch HP L2, notiamo che i led delle porte dove sono collegate le celle sono sempre fissi, come se ci fosse traffico di broadcast.
Non so che fare....
-
I giorni passano e il cliente è incazzato.
Purtroppo quando le cose si mettono male la reazione è quella...bisogna vedere quanto e cosa ha dovuto "sopportare"...ma forse è meglio continuare a conversare sul piano squisitamente tecnico e, d'altra parte, ora c'è in campo direttamente Siemens.
Sebbene abbiamo una rete distinta per il sistema dect formata da switch HP L2, notiamo che i led delle porte dove sono collegate le celle sono sempre fissi, come se ci fosse traffico di broadcast.
Il traffico di Broadcast (di per sè) ci può essere e, in un certo senso, ci deve pur essere...ovviamente nella dovuta quantità (e tale quantità è funzione degli apparati che sono connessi a quello Switch ed è soprattutto funzione dei protocolli di rete che i servizi usati/forniti da tali apparati sfruttano/eseguono).
Sicuramente il Broadcast è confinato entro il dominio dello stesso Switch L2/L3 (nel senso che non va ad interessare altre subnet ed è confinato anche entro ciascuna singola VLAN che si va a considerare...se ve ne sono altre oltre a quella di default): mi viene da chiedere se, ammesso che lo Switch HP in uso sia dotato di Management (via WBM o via Seriale RS.232), si sia data un'occhiata allo stesso (intendo alle impostazioni delle porte, alle VLAN, al Firmware, alla distribuzione di traffico, ecc...) ed alle connessioni cablate (topologia, eventuali Loop di patch cords?) che ad esso fanno capo.
L'analisi deve partire da cose evidenti (e semplici da determinare) fino ad arrivare alle configurazioni...ovviamente le cose che scrivo possono sembrare quasi irriverenti (vuoi che serva preoccuparsi di topologia di rete o del Firmware dello Switch oppure ancora di come sono installate le Patch Cords?)...ma siccome simili controlli si fanno velocemente non costano nulla...e poi ci si può concentrare su un livello più alto: sono rispettate le raccomandazioni sul deployment (le VLAN IDs e la configurazione della BSIP-IWU o del Server IWU) di HiPath Cordless IP?
Magari uno schizzo su un foglio di carta con tutte le indicazioni del caso (stato porte Ethernet, stato delle VLAN per porta, configurazione porte nell'IWU e nelle singole BSIP, ecc...) riuscirebbe a far emergere qualche cosa...ripeto...fatto salvo che lato BSIP sia tutto OK (c'è un altro Thread in questo Forum dove è già stata discussa la cosa tempo fa...).
Usando applicativi come, ad esempio, Wireshark il Broadcast lo vedresti subito...e potresti provare a disattivare la sincronizzazione via PTP (IEEE1588) per vedere come mutano le cose.
State usando per HiPath Cordless IP V1 la (nuova) R4.6.0 oppure la R4.5.0? ...non che poi faccia questa gran differenza se ci sono problemi a monte.
Vedi, a solo titolo di esempio però, l'allegato PDF (è solo la stampa di una voce della KB relativa ai problemi introdotti dal PTP quando non vengono create le VLAN...è, come noterai, alquanto "scarna" in termini di informazione contenuta...tipico di chi scrive le cose pensando che chi legge sappia già come fare tutto o come porre rimedio ai problemi...cosa alquanto paradossale!).
Non so che fare....
Con tutta sincerità non ho alcuna difficoltà ad ammettere di non aver mai partecipato ad un corso (nè teorico nè tantomeno operativo/implementativo) sull'HiPath Cordless IP V1 ma sicuramente, indipendentemente dalle dimensioni dell'installazione, proprio per il tipo di tecnologia che sta dietro al prodotto...ci andrei con i piedi di piombo (sulla carta prima...) per tentare di capire (o farmi una idea su) qual'è la configurazione migliore (ovviamente potendo scegliere apparati, configurazioni e topologia)...dico questo perchè non so se oltre ai manuali (Service Manual/Administration Manual) ci sia qualche dispensa (How-To, Guideline) che spieghi (davvero) passo passo cosa fare, come farlo e perchè farlo...e soprattutto se farlo in funzione di un certo tipo di implementazione (PTP attivo/non-attivo, IWU su BSIP Master o IWU su Server esterno) che si vuole sviluppare (ogni cliente obbliga ad un certo scenario implementativo).
Capisci che intendo dire?
Saluti, Kimera.
-
Certo Kimera,capisco benissimo.
Adesso attendiamo news dal supporto. Speriamo in bene!!!
-
ciao a tutti,
la soluzione "momentanea" (secondo me con le prossime uscite di release del server dect sicuramente apparirà qualche altro bug) del problema della scarsa qualità audio del sistema è la seguente:
Siemens ci ha rilascito una release pilota V1 R4.6.0 rc1 che teoricamente ha risolto il problema di non riuscire ad impegnare la linea al primo tentativo mentre si è in movimento. (presumo sia l'attuale V1 R4.6.1 hotfix).
Il server dect (e naturalmente la stessa cosa vale per la IWU se si ha un sistema con 10 celle al massimo) deve avere attiva la vlan nella lan nella sezione "dect" e nel nostro caso anche nella lan nella sezione "network/gateway" (naturalmente devono essere diverse).
La porta dello switch, dove colleghiamo il server, deve essere tagged sia con la vlan "network" che "dect".
Le porte dove si collegano le celle devono essere untagged solo con la vlan "dect".
La porta di collegamento dello switch con il resto della rete deve essere tagged solo con la vlan "network".
Se si hanno switch periferici, collegati un fibra o rame, le porte di collegamento devono essere tagged con tutte e due le vlan.
E' da un mese che abbiamo effettuato queste modifiche, per il momento non ci sono lamentele, forse il problema è stato "sistemato".
-
Bene.
Se il Ticket è il NA11053175 "Payload is lost during call" allora probabilmente la release che vi hanno dato da provare (V1 R4.6.0 RC1) è ora disponibile come Hotfix V1 R4.6.1.
Il discorso della mappatura con le VLAN richieste e del relativo Port Tagging sulle porte degli Switch coinvolti è sempre "utile".
Saluti, Kimera.
-
Io la parte di configurazione vlan come hai descritto l' avevo preso come must e non come opzione!
Inoltre mi sembra dai test fatti molto importante che la clan dect non debba essere layer3. Insomma niente gateway nella rete degli switch!
-
Infatti ho scritto "utile"...non volevo ripetere (per l'ennesima volta...visti tutti i Threads nei quali queste cose sono state discusse) che la corretta configurazione delle VLAN necessarie (almeno "VLAN Management Network" e "VLAN IP DECT") ed il rispetto dei requisiti richiesti secondo quanto indicato nel Service Manual e nelle varie Release Notes (No Routing, No Layer 3 Switch, ecc.) sono essenziali per non incorrere in problemi ancor prima di iniziare.
Saluti, Kimera.