OpenPath
HiPath / HiCom => HiPath - OpenOffice (LE, ME, EE) => Topic started by: Gen on April 21, 2009, 11:06:59 am
-
Salve a tutti,
Faccio una domanda generica non legata realmente ad OpenOffice ma di un problema che in questo momento ho incontrato su HiPath OpenOffice (R3.5.0_079). Appena potrò verificherò se capita anche con la stessa configurazione su HiPath 2k.
Premetto che sto utilizzando un registrar SIP esterno su HOOME con provider voce McLink. Ho 4 numeri geografici configurati su centralino ognuno con suoi username/pass per l'autenticazione su provider SIP, ed ogni utente effettua chiamate utilizzando il proprio account e quindi col proprio numero esterno geografico voip e quindi con gestione addebiti separata.
Tutto funziona correttamente in uscita, il problema è che durante le chiamate entranti su QUALUNQUE numero geografico (tutti quanti funzionanti e attivi in ingresso) dal momento in cui si è in collegamento senza che la chiamata venga agganciata da un operatore dopo un conteggio di 30secondi esatti la fonia "salta" e non si sente più nulla in 2 sensi, ma la chiamata non cade.. Muto.
Ho questo problema sia con un messaggio della IVR in ingresso di 20 secondi e 10 secondi di squilli finali che per esempio con 30 secondi di squilli senza IVR configurata. (Questo SOLO con chiamate in ingresso su linee/numeri VoIP, su ISDN no)
La cosa strana è che in qualunque caso se anche al 29esimo secondo di attesa un operatore risponde la chiamata viene portata avanti correttamente senza limiti di tempo e la fonia non viene più abbattuta..
Vi è mai capitato?
Ci può essere qualche impostazione da modificare? (nelle temporizzazioni non ho trovato nulla di simile anche facendo alcune modifiche)
Mi porto avanti questo problema da un pò e ancora non sono riuscito a venirne a capo..
Grazie!
ciao ciao
Gen.
-
Scusa ma la R3.5.0_079 è stata rigettata in quanto piena di bug, hai provato con la versione R3.7.0_022?
-
No, son quasi certo però che si verificava lo stesso problema sulla R3.4.0_058 (avevamo solo 1 geografico ma il problema era lo stesso se non ricordo male).
Ho provato a chiedere perchè ho dato per scontato (forse sbagliando) fosse un problema di configurazione o un parametro da modificare.
Se non è mai capitato a nessuno comunque appena riesco aggiornerò alla R3.7.0_022. Grazie
-
...hai provato con la versione R3.7.0_022?
Visto che la sequenza dei rilasci è:
V1 R3.7.0 Build 022 P30152-P1388-P1-45 V1 R3.7.0 Build 022 11.03.2009 R3 Fix Release 7 Hotfix Release 0 (build 022)
V1 R3.7.1 Build 023 P30152-P1388-P1-46 V1 R3.7.1 Build 023 17.03.2009 R3 Fix Release 7 Hotfix Release 1 (build 023 Rejected)
V1 R3.7.0 Build 022 P30152-P1388-P1-45 V1 R3.7.0 Build 022 23.03.2009 R3 Fix Release 7 Hotfix Release 0 (build 022 released for General Availability)
V1 R3.7.1 Build 025 P30152-P1388-P1-47 V1 R3.7.1 Build 025 26.03.2009 R3 Fix Release 7 Hotfix Release 1 (build 025)
V1 R3.7.1 Build 026 P30152-P1388-P1-48 V1 R3.7.1 Build 026 02.04.2009 R3 Fix Release 7 Hotfix Release 1 (build 026)
V1 R4.0.0 Build 013 P30152-P1388-P1-49 V1 R4.0.0 Build 013 09.04.2009 R4 Fix Release 0 Hotfix Release 0 (build 013 eeQS Release Candidate 1)
V1 R3.7.1 Build 031 P30152-P1388-P1-50 V1 R3.7.1 Build 031 16.04.2009 R3 Fix Release 7 Hotfix Release 1 (build 031)
e visto che i bugs (nuovi o redivivi) sono sempre dietro l'angolo...tanto vale fare un pensierino alla R3.7.1 (013). Sulla R4.0.0 sto aspettando dei Feedback...che però tardano ad arrivare.
Saluti,
Kimera.
-
Ciao,
a me è capitato con un telefono SIP con all'interno configurato un provider VoIP (cioè senza passare da alcun centralino) che la chiamata si abbattesse dopo 32 secondi esatti...ho risolto impostando lo STUN...magari ti può essere d'aiuto...
-
Salve a tutti,
A patto che la risoluzione dei DNS si verifichi correttamente e non ci siano problemi legati al NAT, potrebbe essere qualche cosa di molto simile al Ticket NA03637817, risolto con la R3.7.1 (build 031), "Announcements longer than 30 seconds stopped playing if incoming calls via SIP-Provider or IP-Trunking were forwarded to AutoAttendant." anche se non viene citato il caso (come tu hai riportato) che si verifica anche quando la chiamata entrante è diretta ad un interno senza passare per l'IVR (e quindi senza l'intervento di AA/Risponditore con annessi annunci).
Prova quindi ad aggiornare il sistema.
Saluti,
Kimera.
-
Ciao,
a me è capitato con un telefono SIP con all'interno configurato un provider VoIP (cioè senza passare da alcun centralino) che la chiamata si abbattesse dopo 32 secondi esatti...ho risolto impostando lo STUN...magari ti può essere d'aiuto...
Alessandro: Ho provato ad impostare un server STUN esterno ma non è cambiato nulla (oltre che interpellando McLink mi han detto che loro non lo usano e nei loro "servizi voce" non è supportato).
Kimera: Dopo aver letto il tuo post mi è venuto il dubbio e ho provato a verificare nuovamente cosa succedeva con le chiamate dirette.. Effettivamente non ho problemi mi ero sbagliato, quindi è molto probabile che il problema sia quello del ticket da te indicato! Appena metto in mezzo l'AutoAttendant dopo quei 30secondi salta la fonia.
Ora appena riesco aggiorno alla 3.7.1 anche se ho sempre scaricato versioni General Availability e questa release Pilot Usage non riesco a scaricarla, mi chiede un Auth Code, che ho provato a richiedere.
Grazie mille x l'aiuto!
-
Ciao Gen,
non posso sottrarmi dal fare una considerazione leggendo ciò che hai scritto sulle Release disponibili (una considerazione forse un pò provocatoria, ma pure sempre una considerazione): come si può accettare che una Release venga dichiarata GA (quindi il suo uso sia caldeggiato/consigliato) se una Release successiva, pur in fase FT/eeQA, presenta poi molti meno bugs o molti più bugs corretti ? ...lecito chiederselo, almeno in prima istanza, sempre che, di bugs, non ne vengano introdotti di nuovi.
In linea di principio un software dovrebbe essere (dichiarato) GA solo quando è veramente molto stabile per quanto concerne le sue specifiche/i suoi servizi di base...invece mi rendo conto che ci sono molti rilasci GA alle volte non proprio all'altezza di cui, personalmente, non mi fiderei più di quanto non mi fiderei di un rilascio FT/eeQA.
Saluti,
Kimera.
-
sempre che, di bugs, non ne vengano introdotti di nuovi.
Il problema è proprio questo! Sistemano una cosa e ne incasinano tre...
Mah...
-
Ciao -clever-
che bello: siamo sulla stessa lunghezza d'onda (la mia precisazione non è stata messa lì a caso).
Mah...alla fine mi viene da pensare che siano (e, di conseguenza, siamo) sperimentatori...sulla pelle del Cliente ma alla faccia nostra.
A questo punto una domanda è quasi d'obbligo: che approccio di (sviluppo del/marketing) prodotto hanno mai adottato con l'HOOME? (ed in Germania come sta andando ?).
Allo stato attuale delle cose...l'approccio adottato, qualsiasi esso sia, mi sembra alquanto discutibile o, per lo meno, opinabile...e mi sembra che esso sia anche leggermente poco logico rispetto agli approcci tipici adottati da Siemens per i prodotti a cui eravamo abituati nel passato: capisco che la complessità del prodotto (penso soprattutto alla parte software) non sia paragonabile con la complessità dei prodotti hardware del passato...ma le buone abitudini (in-house testing o rilasci sicuri solo dopo alcune buone prime Minor Releases...ad esempio) sembra che se ne siano andate come se ne è andata la vecchia guardia...non ho difficoltà ad immaginare che la situazione sia cambiata così: niente più tedeschi quadrati che testano fino alla nausea al banco ma un'altra schiera di sviluppatori Russi o Polacchi (o Indiani tambien) che di "telefonia" sanno quel poco che basta ma di Linux e applicazioni Real Time sono Guru e sfornano linee di codice per tutti i gusti (bugs e correzioni comprese).
Bello no come quadrettoimmaginario ? intanto andiamo avanti. Al prossimo Upgrade.
Saluti,
Kimera.
-
Si in effetti ogni tanto mi chiedo se anche in altri paesi, Germania per prima ci siano le stesse problematiche e come le affrontano...non solo comunque HOOME ha tutti questi "buchi".
Mi sembra che ultimamente anche gli altri prodotti stiano subendo un calo a livello di operatività...mah...speriamo in bene...
-
Ciao a tutti,
come direbbero i Cesaroni
che amarezza....
Micche
-
Io ho un problema analogo con linee sip di Mclink però con OpenOffice EE
le linee si registrano correttamente sul provider , le chiamate sia in entrata che in uscita funzionano correttamente e anche con buona qualità della voce ma metto in attesa (sia per le chiamate entranti che per le uscenti) e poi o passo la chiamata o riprendo la chiamata non c'è più fonia da entrambe le parti.
Qualcuno sa cosa potrebbe essere ????
-
Ciao,
domanda di rito: che versione APS ha l'HOOEE ? è un HE682Y.00.010 o HE682Y.00.012 oppure una delle versioni APS rilasciate precedentemente ? (per inciso, la HE682Y.00.012 è rilasciata ma non per effettuare SIP IT SP Trunking).
Saluti,
Kimera.
-
E' in versione HE681Y.00.028.
Ma scusa quelle che mi hai elencato sono versioni rilasciate e disponibili su SEBA???
Io avevo guardato qualche giorno fa ma non mi sembrava ci fossero relaese nuove.
-
Ciao,
fai finta che non ho scritto nulla... ;-)
Comunque la sequenza dei rilasci è (dovrebbe essere), ora come ora, questa:
V1 R1.0.0 (003) HE681Y.00.003 29.08.2008 Field Trial (primo rilascio per FT).
V1 R1.0.0 (021) HE681Y.00.028 25.09.2008 Field Trial.
V1 R1.0.0 (028) HE681Y.00.028 21.11.2008 Major Release ---> GA (General Availability).
V1 R2.0.0 (001) HE682Y.00.001 24.01.2009 Field trial.
V1 R2.0.0 (010) HE682Y.00.010 24.03.2009 Hot Fix.
V1 R2.0.0 (010) HE682Y.00.010 31.03.2009 Minor Release (come la precedente) ---> GA (General Availability).
V1 R2.0.1 (012) HE682Y.00.012 04.05.2009 Hot Fix ---> LA (Limited Availability).
Non so su SEBA cosa ci sia attualmente ---> anzi, correggo il tiro: su SEBA c'è tutto ma con tutta probabilità le versioni in oggetto sono ancora considerate FT/eeQA e quindi non disponibili ai più.
Saluti,
Kimera.
-
Per quanto riguarda i problemi di fonia su voip, volevo segnalare una prova fatta ieri, con un account del provider voip Telesya.
La linea funziona, la chiamata va in uscita e in entrata, ma sulle chiamate entranti,anch'io ho verificato che se la chiamata viene messa in attesa, quando viene ripresa, dopo circa 2 secondi la fonia scompare (quella dal chiamante esterno verso l'utente di hoome, invece rimane attiva nel senso opposto).
Ho fatto qualche prova con un softphone tipo x-lite, ma non ci sono i problemi di fonia riscontrati con la centrale Hoome.
La relese della centrale è la 3.7.0_022
Ciao.
Bandieranera.
-
Ciao a tutti,
Nel mio caso penso alla fine sia un problema di porte (il problema mi si verifica solo in ingresso ma anche senza mettere in attesa).
McLink mi ha detto che (a parte la porta 5060 per la segnalazione) è necessario aprire TUTTE le porte UDP dalla 10000 in poi, e non soltanto un range dato che non vengono utilizzate in modo sequenziale. Quindi dalla 10000 alla 65536.
Mi han detto che in alcuni casi quando capitava una chiamata entrante sul canale UDP senza nat si aveva una comunicazione senza fonia in 2 sensi (ma con segnalazione, porta 5060 ok).
Ps: Il server STUN mi è stato riconfermato nuovamente da McLink che non viene in alcun modo utilizzato nei loro Servizi Voce.
Vediamo se risolvo aggiungendo un nuovo IP statico (dedicato) o cambiando router, dato che con questo non riesco ad aprire un range così grande di porte.
Grazie, vi faccio sapere se risolvo
-
scusa ma perché non provi a fare una chiamata con uno sniffer di rete attivo e a vedere effettivamente le porte che usi?è vero che sono random, ma di solito usano sempre lo stesso range...
-
Ho provato a far tracciare da McLink una chiamata in ingresso ma non siamo riusciti a capire comunque quale poteva essere il problema. Mi han detto che non viene usato un range ma "tutte" le porte dalla 10000 in poi. Quindi un bel range..
Ora un collega configura un nuovo IP pubblico dedicato che abbiam preso aggiuntivo e vedo se si risolve qualcosa.
-
Ciao,
Alla fine abbiam cambiato Firewall e configurato i nat della porta 10000~40000 e della 5060 e non abbiamo avuto più il problema delle chiamate senza fonia.
McLink inizialmente aveva detto 10000~20000; poi TUTTE le porte dalla 10000 in poi, ma provando mi sono reso conto che la fonia in quel modo era completamente compromessa.
Alla fine mi han consigliato un range dalla 10000 alla 40000 in quanto spesso vengono utilizzate anche porte alte.
Mi è rimasto comunque il problema della caduta della fonia nelle chiamate su linee VoIP registrate con McLink durante la ripresa della telefonata dopo una consultazione; problema che si verifica occasionalmente. Questo su praticamente tutte le versioni di HOOME se non ricordo male.. (non ho ancora provato le MR4)
Ho saputo che un collega partner ha lo stesso problema, e sempre su HOOME registrato con McLink, ma non riusciamo a risolverlo in nessun modo.
Ciao,
Gen.