OpenScape > OpenScape - Office (OSO MX/LX/HX)

Rete OSOMX V3 <> HOOEE

<< < (2/3) > >>

v.incenzo:
Ciao, col sip nativo non riesco a comunicare tra OSOMX e HOOEE, ho rpovato a cambiare il flag monitoraggio del nodo nei nodi ma nulla, l' Alive Monitoring l'ho lasciato su PING come dice la service relativa al sipq tra OSOMX e Hipath 3000.
Codec e lunghezza del frame coincidono su tutti i pabx.
Sto andando un pò a caso, lo ammetto.

Sono tentato di collegare un HOOEE sulla lan dell' OSOMX e metterlo in rete localmente per vedere come si comporta, devo capire se lavorare sulla vpn o cosa.

French:
Ciao,
alcuni post più indietro si è già parlato di un caso simile, ho avuto un caso simile 5/6 anni fa, in quel periodo c'era l'HOOME1 e già quella volta il networking con l'HOOEE V1 non funzionava ( la chiamata andava ma non c'era fonia).
Per risolvere ho dovuto aggiornare l'HOOEE alla V2 (il problema è trovare le licenze).
Il monitoraggio l'ho tolto sui HOOEE e l'ho lasciato attivo sull'OSOMX.

Kimera:
Se è per questo non credo infatti sia mai stato indicato esplicitamente (da Siemens) che un OpenScape Office MX V3 possa essere interconnesso senza problemi con l'HiPath OpenOffice EE V1...anzi, direi che se ti vai a guardare le RN o i manuali, si sono sempre premurati di indicare a chiare lettere (magari con un Font piccolo) che le interoperabilità tra sistemi sono testate per sistemi della stessa versione software, alle volte solo tra le stesse famiglie Hardware (MX V3 con MX V3, EE V2 con EE V2, ecc.)

Il tutto a discapito del fatto che si vadano ad usare protocolli di Trunking teoricamente Standard (con la "S" maiuscola), presunti sempre uguali a sè stessi o, per lo meno, retro-compatibili ed interoperanti tra le varie versioni dei sistemi (Ad esempio: SIP, SIP-Q o CorNet-IP funzionanti per qualsiasi combinazione di sistemi e di versioni si intenda attuare). Ci hanno insegnato che così non è (almeno non sempre)...altrimenti non potrebbero così facilmente giustificare il fatto di doverti vendere non solo del nuovo Hardware (+Licenze) ma di doverti far cambiare anche tutto quando a questo era interconnesso.

E' evidente che se le uniche due cose che sono cambiate sono: un nodo ed il Protocollo di Trunking che questo nodo utilizza per interconnettersi agli altri nodi (e tutto il resto è rimasto tal quale), allora proprio quelle modifiche sono la causa. Prima cosa usavate tra i nodi? CorNet-IP? I Trunking VPN fanno passare tutto (tutte le porte, tutti i protocolli)?

Saluti, Kimera.

v.incenzo:
Ciao a tutti,
pare che le vpn con le sedi remote non siano più stabili come prima, ho controllato saltuariamente da remoto il firewall nodo 1 e ho scoperto che a volte è giù la vpn con il nodo 2, a volte quella col 3 e coì via fino al 5, a volte sono tutte giù o solo 3 su 5 ecc.
Le adsl per le vpn sono dedicate al voip, la navigazione è assicurata da altro router (tutte adsl Alice).
Può essere che lo scambio dati in SipQ sia talmente basso da far chiudere le vpn ?
Inoltre le comunicazioni tra nodi sono scarse comunque, visto che sono negozi, non ci sono nemmeno PC che lavorano in rete con il nodo 1.
I firewall Watchguard Edge X55e in questione pare che non abbattano la connessione in caso di scarso traffico, infatti non ho trovato parametri tipo "Always Up", e il manuale dice chiaramemente in merito alla disconnessione: " do not do this ".

Oppure c'è troppa latenza sulla adsl nodo 1 e quindi il problema è lì, le vpn vanno giù per condizioni di rete insufficienti.
Innanzitutto dovrò trovare la soluzione per la stabilità delle vpn, poi vedrò per le comunicazioni tra OSOMX e HOOEE.

Ciao

Kimera:

--- Quote from: v.incenzo on September 24, 2014, 05:52:37 pm ---Può essere che lo scambio dati in SipQ sia talmente basso da far chiudere le vpn ?
--- End quote ---

Tecnicamente parlando: se due Firewalls instaurano un VPN Trunk (Site-to-Site, non stiamo parlando di un VPN Client-to-Site dove il VPN Trunk viene creato su richiesta del Client) quest'ultimo è matenuto attivo fintantochè è stabilito dalle impostazioni degli stessi Firewalls (in genere, se non ci sono problemi di connettività ad un livello più basso, ad esempio sulle linee xDSL, un Trunk VPN può arrivare ad avere un "uptime" molto alto...per la gioia di chi quel VPN Trunk usa tutti i giorni);  non vedo poi perchè debba essere la quantità/qualità del traffico (o una sua fantomatica soglia) che fluisce attraverso tale VPN Trunk a stabilire quando questo deve decadere! ...ovviamente a meno che non ci sia un meccanismo del tipo "tieni aperta la connessione solo se rilevi traffico tra i nodi" (e, in questo caso, si dovrebbe valutare di che traffico si parla se non basta nemmeno un Ping tra i nodi - una sorta di Watchdog - per generare quel minimo che basta per tenere attivo un Trunk).

Saluti, Kimera.

Navigation

[0] Message Index

[#] Next page

[*] Previous page