...ma ancora mi sfugge il motivo per il quale hai scritto quello che hai scritto come l'hai scritto...solo per dire che in Siemens non progettano/realizzano delle sciocchezze che invece un "cantinaro" è più predisposto a fare (sperimentando con Linux, ovvio!)

Non ho parlato di "sciocchezze" ho detto che non abbiamo a che fare con un "cantinaro" che sta mettendo su una paittaforma telefonica e che non avendo un, chiamiamolo così, "controllo qualità", in genere mette in giro distribuzioni buggate risolvendole (se è in grado) man mano che i clienti acquistano il suo prodotto e lo provano, spesso e volentieri lasciando anche dei "bachi giganteschi" nella sicurezza o nell'utilizzo per giorni, settimane, mesi...

Ti faccio un esempio pratico.

Qualche tempo fa abbiamo acquistato un APP su Google Play, in Java compilato con l'SDK Android. Ebbene utilizzandolo il software presentava diversi BUG, alcuni abbastanza insignificanti, altri ne rendevano praticamente impossibile l'utilizzo corretto.

Ho segnalato i bug allo sviluppatore, per i bug semplici ci è voluto qualche giorno, per i bug "complessi" ci è voluto più di un mese...e alla fine senza risolverlo e sai cosa mi sono sentito dire!? "Io non sono uno sviluppatore Java, lo faccio nel tempo libero quindi..." (non rompermi i coglioni) l'ultima parte l'ho aggiunta io anche se era sottointesa.

Quindi: ho dovuto decompilare il codice dell'APK e cercare di capire dove stesse il problema. Ci ho messo giorni, rottura di scatole, e sbattimento, perchè JAVA sembra qualcosa che nessuno sa bene che forma abbia, quindi facendomi aiutare da dei tutorial trovati su internet e da altri sviluppatori più o meno esperti su dei forum, e armato di una pazienza biblica, e della consueta sagacia del tecnico (ossia continuo a provare e a sbagliare finchè non lo faccio giusto) alla fine ho risolto il problema autonomamente.

Ora capisci a cosa mi riferisco!?

Riesci ad immaginarti una persona che si mette a decompilare il codice del sistema operativo (chiamiamolo così) dell'HiPath 3500 o dell' OSBiz per risolvere un bug!? Io no. Avrei aperto un ticket sul portale di Unify e avrei atteso la soluzione o una risposta di un work around.

Questa è la differenza tra un "cantinaro" e un grande distributore.

Quote from: Hunter on April 17, 2014, 01:26:54 pm

ma comunque sia non stiamo parlando del cantinaro che ha deciso di buttarsi sul SAMBA di Linux e sta cercando di mettere in piedi una piattaforma telefonica.

Ovvio. Solo aziende del calibro di Siemens (Unify) riescono a fare sviluppo a "quei" livelli.

Un appunto: non facciamo però FUD su Linux tirando in ballo paragoni impossibili...chissà come mai...ma in anni di attività ho visto più "cantinari" che si spacciano per IT Manager di infrastrutture Microsoft (visto che sono la maggioranza...il rischio di trovarne di incompetenti è davvero molto alto) che altro...citare (il servizio) SAMBA ed associarlo ad (appliance) IP-PBX basati su Linux ed Asterisk (per puro esempio) mi sembra un abbaglio: non ho ricordi di aver avuto contatti con un sistemista IT Linux o un'azienda seri (ripeto: seri) che implementassero SAMBA su un'appliance specifica (esempio: FreePBX Distro? AsteriskNow? sipxecs? Gigaset T300/T500 Pro?) - ovviamente a meno di non dover sottostare a richieste specifiche - ma, si sà, un conto è colui che "gioca" per provare un applicativo/servizio...un altro colui "che pensa" l'uso di un applicativo/servizio in termini di affidabilità, manutentabilità e sicurezza per poterlo inserire ed usare in azienda. Due mondi diversi per due teste diverse con visioni diverse.

Saluti, Kimera.

Non ho capito bene quello che cerchi o hai cercato di farmi notare. SAMBA è un servizio che gira anche sull'Open Office MX se è per quello, ma il termine "cantinaro" non è usato in termine denigratorio o dispregiativo, era solo un modo per dire che un prodotto come OSB ha alle spalle un infrastruttura che, "di base", non credo metta in giro una distribuzione con bug simili, secondo, chiude il baco simile nel giro di qualche giorno al massimo.

Per quello che mi riguarda, io in primis mi metto a "paciugare" su apparati Cisco, in casa o al lavoro per hobby o per verifcare delle funzionalità, ma non per questo mi spaccio per un sistemista Cisco. 

Curiosità Off Topic: avevate preso in considerazione (ad esempio) l'opportunità di affiancare all'HiPath 3800 V9 (rimodulando la configurazione relativa alle VMs e/o agli Auto-Attendands ed relativi moduli fisici coinvolti) una piattaforma quale l'OSO LX oppure l'OSO HX?

Bè difronte a una situazione del genere io non so se avrei affiancato un 3800 ad un LX-HX. Credo che sarebbe stata una gestione più complessa del sistema. Onestamente ho sempre preferito le soluzioni "all-in-one" nella fattispecie OSO MX piuttosto che HiPath 3000 con server OSO. Vero che in definitiva ottieni gli stessi servizi, anzi, forse qualcosa di più peculiare, ma credo che la gestione di due apparati, che si parlano, è vero, ma che devi controllare e manutenere in ogni situazione, alla lunga creino un doppio indice di criticità, che su un sistema del genere, deve essere preso in considerazione.

hanno risposto semplicecemente....Dear Mr. Becciu, please purchase the 19 licenses TDM to the customer.
quindi visti i tempi che corrono ( e quello che costano ) al cliente proveremo a fatturare queste nuove licenze NON PREVISTE... spenrando bene...

Non è proprio una bella considerazione dei Partner...

 

Ma che razza di risposta è!? 

Onestamente avrei risposto con una serie di improperi di vario genere.

Devo dire che il sistema di migrazione delle licenze comunque è di una stupidità disarmante. Semplicemente avrebbero dovuto "conteggiare" gli utenti TDM in base all'equipaggiamento di macchina e non al database perchè chiaramente essendo noi "umani" possiamo commettere errori, errori che tra l'altro non sono evidenziati, perchè sul manuale di migrazione non è scritto da nessuna parte di inserire gli utenti con nome e numero di interno, nè di scollegare eventuali optiset e sostituirli con openstage o optipoint, non è spiegato come vengono "licenziati" i VM, non è evidenziato che i dect passano da confort a GAP e queste per ora sono le cose più evidenti che abbiamo verificato. Ma immagino che che ne saranno altre. 

Credevo he la parola "partner" significasse che remiamo tutti dalla stessa parte, ma mi rendo conto che non è per niente così.

C'è di che rimanere sconcertati...evidentemente, viste le esperienze tecniche di migrazione tutt'altro che "lineari" da voi riportate, c'è di che riflettere prima (e, aggiungo pure, al solo pensiero) di passare ad OpenScape Business V1 un sistema che si trova stabilmente in HiPath 3000 V9...personalmente rimango dell'idea che il Vendor abbia complicato molto le cose e mi chiedo: tutto questo a chi giova alla fine (a migrazione conclusa/vendita delle licenze conclusa)? al Vendor? al Partner (che diviene/oppure è già un Partner "sistemistico")? ad entrambi? al Cliente?

Onestamente l'unico vantaggio che ho riscontrato nel fare l'upgrade è che l'OSBiz ha una sorta di HG1500 integrato, che le BS4 hanno 4 canali e non vanno licenziate, e che espandere il sistema ha un costo relativamente più basso, perchè se avevo necessità di 15 interni dovevo forzatamente acquistare una scheda da 8 Up0e o 4 BCA, mentre ora il costo della scheda è più basso ma devo pagare le licenze. Per il resto migrare da un HiPath 3X V.9 a un OSBiz non so se il gioco valga la candela. 

Ciao a tutti,

mi hanno fatto una domanda alla quale effettivamente non sono riuscito a dare una risposta.

Un cliente ci ha chiesto se è possibile aprire la scheda cliente un suo CRM, all'arrivo della chiamata del cliente specifico, tramite il numero telefonico.

Nell'App Launcher ho notato che è possibile aprire un file batch o un url a seconda del chiamante, quindi...in teoria, è possibile, avete qualche esperienza in proposito!?

Stesso "problema" che abbiamo riscontrato noi. Metto problema tra virgolette, perchè in realtà io non so se quella è un anomalia o la normalità. So solo che i primi due upgrade che abbiamo fatto i file xml erano diversi ed indicavano chiaramente quanti utenti TDM c'erano e quante licenze c'erano. 

In teoria se i terminali registrati sul sistema DECT di un OpenScape Business Xx V1 vengono rilevati come terminali DECT GAP (ad esempio potrebbe essere benissimo essere il caso di un Gigaset SL610 Pro) il CLIP non si dovrebbe vedere in ogni caso...

Saluti, Kimera.

Si, abbiamo appreso anche noi che sui terminali SL610 PRO non si vede il CLIP. La cosa strana è che sulla V.9 il CLIP si vedeva, quindi risulta difficile dare una spiegazione al cliente che si vede privato di un servizio che prima aveva. Mha...misteri della Unify, però mi piacerebbe che qualcuno mi desse una spiegazione di questo, altrimenti fare Upgrade su versioni "obsolete" che hanno un sistema DECT sarà sempre più sconsigliato. 

Vi ringrazio tutti per le risposte.

Mi è piaciuto particolarmente apprendere che il Manager E avvisa il Tecnico che le schede presenti nella centrale non sono compatibili, mi pare molto user friendly, una modifica che si chiedeva già da un po' di tempo.