OpenPath
OpenScape => OpenScape - Office (OSO MX/LX/HX) => Topic started by: Gen on October 28, 2013, 10:47:55 am
-
Buongiorno a tutti,
Vi parlo di un OSO LX virtualizzato con VMware Workstation 9.0.2 build-1031769 su server con Windows Server 2012 Standard; OSO LX V3 R3.7.0 (009).
Il sistema funziona regolarmente, con tutti telefoni HFA (40,60,80 tutti con release V2 R1.2.1), e come linee ho registrato un provider SIP MC-link con 4 canali VoIP, ho però seri problemi di perdita di fonia:
- Ricevo una chiamata esterna sul numero MC-link, tutto ok, premo consultazione e compongo un numero esterno (anteponendo ovviamente lo 0 ed impegnando un'altra linea), la consultazione è OK, ma appena trasferisco la chiamata la segnalazione rimane UP ma la fonia no... :-\
- Dopo circa 2 giorni (praticamente a centrale inutilizzata in quanto solo in test) non sento più fonia nemmeno effettuando normali chiamate esterne e ricevendone, riavvio la centrale e tutto magicamente torna ok...
Consigli? E' successo a qualcuno?
Ho qualche flag particolare da impostare sulle linee VoIP in Modalità esperti>Linee/Routing>Linee>LAN>Box:1,Slot:1>Port 7 Provider 1> Cambia flag ISDN ?
Le linee MC-link da sempre non sono certificate ma ne ho già installate parecchie con OSO MX, OpenOffice V1 e V2 (mai OSO LX), e non ho questo problema, per di più si tratta di un'installazione pulita senza particolari configurazioni e con tutte le ultime release.
Grazie a tutti,
Gen.
-
Ma le linee alle quali ti stai riferendo sono ISDN (quindi chi fa da Gateway all'LX?) oppure ti stai riferendo solo ad un SIP Trunking?
Saluti, Kimera.
-
come linee ho registrato un provider SIP MC-link con 4 canali VoIP, ho però seri problemi di perdita di fonia
Ciao Kimera, è un SIP Trunking, nessun gateway per ora!
Thanks
-
Non capivo il riferimento al "Cambia Flag ISDN"...comunque hai provato a verificare che il timing sia OK (NTP a tutti i livelli)?
Nel primo caso...trasferimento di chiamata, l'utente a cui tenti il trasferimento risponde prima che tu riagganci per il trasferimento oppure fai un trasferimento forzato durante la consultazione?
Saluti, Kimera.
-
Nel primo caso...trasferimento di chiamata, l'utente a cui tenti il trasferimento risponde prima che tu riagganci per il trasferimento oppure fai un trasferimento forzato durante la consultazione?
Se faccio consultazioni o trasferimenti interni va tutto bene, se invece faccio una consultazione oppure una trasferta usando lo 0 (quindi impegnando una linea esterna) succede che la persona che chiamo impegnando la seconda linea mi sente da OSO, appena cerco di mettere in comunicazione i 2 esterni (sia in caso di consultazione e trasferta che di trasferta forzata) tra loro non c'è fonia, in nessun senso.
Non capivo il riferimento al "Cambia Flag ISDN"...comunque hai provato a verificare che il timing sia OK (NTP a tutti i livelli)?
Scusa l'ignoranza, ma gli NTP in caso di LX devo impostarli su OSO o su SLES11? Ecco cosa avevo impostato appena installato il sistema:
(http://www.trecentoundici.com/upload/oso_lx_vmware_ntp.jpg)
Devo fare altro?
Thanks, come sempre.
Gen.
-
Aggiungo qualche informazione:
1. Ho provato a disattivare SIP tramite UDP e l'ITSP non si registra più
2. Stessa cosa accade se tolgo il server STUN MC-link
3. Se aggiungo il Proxy Outbound (prima disattivato) puntando il server SIP MC-link non cambia nulla, si registra ma non passa fonia su trasferta esterna esterna.
4. Mi perde la fonia sia su chiamate solo da reti GSM, che da ISDN Telecom che da VoIP MC-link, anche mixando i vari gestori.
Ho dubbi sulla configurazione dello STUN..
Alla voce "Rileva tipo NAT" mi da esito "Tipo di NAT trovato: Firewall restrittivo (UDP) - VoIP non possibile".. anche se son quasi sicuro di aver visto questa dicitura. Qui in azienda non è installato un firewall, l'OSO punta direttamente il router, e comunque la segnalazione non si perde mai.
Saluti
-
Una cosa alla volta.
NTP: se c'è su SLES bene, su OSO (LX) penso che tu debba almeno verificare che sia impostato e che si riferisca a sua volta a SLES (se SLES fa da NTP server e non solo da Client per se stesso) o ad un NTP esterno (come nel caso del setting apportato a SLES)...tecnicamente, per non inondare gli NTP server esterni, basterebbe avere una sola macchina che funge da NTP Server per la subnet e far lavorare quella (serve l'interno e viene servita dall'esterno).
Non entro nel merito della virtualizzazione così come l'hai implementata (avrai le tue ottime ragioni...e beato tu che puoi testare simili cose).
Piuttosto potrebbe essere un problema di compatibilità tra come OSO (LX) effettua la trasferta (con REFER o con INVITE) e come l'ITSP la gestisce (Diversion Header field)...ma se lo fosse...dovrebbe esserci anche con OSO MX (a parità di ITSP e di condizioni di chiamata).
E' che entriamo in un campo minato...ecco perchè Siemens sul Wiki ha posto dei documenti per certificare gli ITSP (proprio per gestire i test di interoperabilità con le proprie piattaforme in modo rigoroso e sistematico, vedi qui (http://wiki.unify.com/wiki/File:VOIP_provider_data_collection_and_test_list.zip)).
Un pezzo interessante (anche se non so se propriamente attinente visto che la trasferta inizia da dentro il sistema e non è un redirect fissato a priori):
"Transfer and redirection
REFER and 302 (Redirect/Diversion) handling are deactivated on the ITSP interface due to security considerations.
Handling of these messages would mean to create new calls to a number that was provided by an external, possibly untrusted, party, which may result in high costs (toll fraud).
The HiPath/ OpenScape Office system does not send REFER or 302 to the ITSP leg, too."
Saluti, Kimera.
P.S. ;D
Ti prego...cambia quel Wallpaper...è pur sempre un Server! Poveri noi!
-
Per quel che riguarda l'NTP server, se non ricordo male, su linux NTP daemon è automaticamente sia client che server (ma Kimera sicuramente ne sa più di me).
Per quel che posso immaginare, nella mia ignoranza in materia, il problema è che quando instauri la seconda chiamata esterna utilizzi porte UDP di fonia diverse da quelle della prima chiamata, e nel momento esatto in cui colleghi le 2 chiamate il signaling ovviamente gira in modo corretto, ma il payload gira su porte UDP diverse, e quindi non sentirai mai.
Io quasi quasi direi che OSO non reindirizza in modo corretto le porte, ma sicuramente Kimera ne sa + di me.
Dico una cazzata...provare ad impostare OSO come STUN server? Non l'ho mai fatto...la butto lì.
Saluti a tutti
-
Per NTP direi di sì (può fungere da Server e/o Server+Client): dipende dallo stato di due direttive nel file di configurazione /etc/ntp.conf (direttive: restrict e broadcast), tipo se hai (non commentate):
restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
broadcast 192.168.1.255
allora consenti lo scambio ora sulla Subnet e l'interrogazione (senza modifiche) da parte dei Clients della Subnet (192.168.1.0/24).
Verifica sul Server (e/o sui Clients) che la sincronizzazione funzioni (ovvero che l'host la stia ricevendo): ntpq -p (nota i valori di Delay/Offset e Jitter non nulli).
Ovviamente poi ci deve essere una regola sul Firewall della macchina che esegue l'ntpd che permetta traffico in ingresso su UDP/123.
Per il resto chino il capo...mi chiedo: il problema sussiste anche se al posto dell'OSO LX fai una prova con un OSO MX? se fosse così allora non funzionerebbero le trasferte esterna-esterna attraverso un SIP Trunking...mi pare strano!
Saluti, Kimera.
-
Altra domanda: negli altri impianti che hai montato funzionanti il router è lo stesso?
Hai provato anche con un altro gestore? Che so...messagenet ad esempio...
-
Chi mi spiega perchè se imposto una deviazione esterna dagli inoltri sullo stesso fascio invece la fonia c'è?
Non ha senso :o
-
Invece potrebbe avere senso. Hai già installato wireshark sul server?
Prima però do ragione a Kimera...cambia lo sfondo :D
-
Riguardo l'NTP e OSO LX una precisazione: sono sufficienti e corrette le impostazioni YaST2 del Server SLES 11 SP2 (32 bit) sul quale l'OSO LX sta girando per dare una base oraria di riferimento ad OSO LX stesso (probabilmente era prevedibile).
Ho visto che in KB ci sono parecchi riferimenti a problemi sul Payload (No Audio) in caso di chiamate trasferite.
Ho anche visto che è un prova (penso F.T. o comunque in Test) una Release OSO LX V3 R3.7.1 (011) ma non ho ancora dato una occhiata alla R.N.
Sarebbe interessante vedere se è un problema legato al Router SE l'ITSP è testato (precedentemente) e quindi Wireshark è d'obbligo almeno per farsi una idea di cosa succede (la butto sul piatto delle ipotesi - soprattutto per i blocchi dell'OSO LX con necessario riavvio dell'intera macchina: Attacchi SIP (DoS)? hai provato a monitorare il SIP Trunking e l'OSO per assicurarti che non ci siano attacchi o tentativi di registrazione malevoli?)
Saluti, Kimera.
-
Ciao a tutti,
Andando con ordine..
NTP: a questo punto allora penso che la configurazione di NTP sia corretta, anche se come già detto in vari post purtroppo non sono un esperto in Linux.
Ho provato ad impostarel'OSO come STUN server ma non si registra più (o intendevi installare qualche servizio su SLES11 per rendere il server Linux un "server STUN"?)
Punto importantissimo: lo sfondo l'ho messo tutto nero!! xD
Router e ITSP: Il router in questo caso è un Fritz!Box 7270, che per di più ha già dei suoi cavolo di NAT interni relativi al VoIP (essendo un gateway predisposto per "fare VoIP", e non fare da gateway ad un altro apparato VoIP interno), ho in programma da giorni infatti di provare con un altro router molto più semplice tipo un Draytek Vigor (MC-link li fornisce come standard). Nell'altro caso ho provato con un MX e un altro modello di Fritz!Box e funzionava la trasferta esterna esterna.. C'è anche da dire che era un OSO MX di molte release fa, quindi trobbe variabili.
Per quanto riguarda l'ITSP purtroppo posso utilizzare soltanto MC-link, siamo partner e ci appoggiamo soltanto a loro da quasi 10 anni.
Sono d'accordissimo anche sul fatto che sicuramente durante l'inoltro succede qualcosa di strano con le porte UDP, che cambiano o qualcosa di simile, e si perde il payload.
Wireshark: altra cosa che sicuramente è fondamentale fare e voglio fare, il fatto è che installare Wireshark su SLES11 per me è un serio problema...
PS: Un altra cosa assurda è che con un client SIP (3CXPhone) riesco a connettere tranquillamente da PC in wi-fi (user: 104, pass: 104) mentre da iPhone non c'è verso di connettere (con gli stessi parametri identici, e da iPhone pingo senza problemi l'OSO). Bah!
-
Allora...
1 - Per lo sfondo...ok!
2 - Wireshark dovresti installarlo tranquillamente tramite zypper o gestione pacchetti su Yast2.
3 - Utente e password 104??? Io cambierei subito!
4 - Il client su Iphone e 3cx Phone si registrano in udp? Tcp? (sempre con wireshark scopriresti cosa non va)
5 - Registrarsi su messagenet è gratuito, solo per fare dei test. Poi ricarichi con 5€ se vuoi fare chiamate esterne. (che poi sono 5€ che aiutano molto in questi casi)
6 - Su deviazione probabilmente funziona perchè la chiamata (la "sequence") alla fine è la stessa e quindi non ha bisogno di creare un altro invite e quindi di usare altre porte per il payload.
Ma io darei precedenza ai punti 2 e 3...
-
Grazie Alessandro.
Per quanto riguarda Wireshark appena potrò fare delle verifiche ti/vi aggiornerò.
Per quanto riguarda il client SIP ho provato a cambiare user e pass mille volte: da PC funziona e da iPhone no (qualsiasi iPhone con qualsiasi App 3CXPhone).
Ho lasciato l'interno come user e pass per partire da una base semplice.
Lasciando tutto di default (come su PC) imposto nome, utente, id, password, server sip interno e basta; PBX port quale usa OSO? Immagino 5060.. Trasporto di default UDP, ma anche TCP non va, stun lascio quello 3cx come su PC, Aiutante NAT ON (anche OFF non va).
Qualche consiglio? Non esistono dei software Siemens/Unify dedicati per connettere un iPhone ad OSO, vero?
Grazie.
-
L'utente 104 è un sip client? Hai configurato l'autenticazione sulle impostazioni workpoint del telefono su OSO?
-
Si è un Client SIP ed ho impostato l'autenticazione, altrimenti non andrebbe nemmeno da PC.
Da PC con 3CXPhone connette istantaneamente (On Hook) mentre da telefono no.
Ho rifatto un user SIP chiamato 145, la situazione non cambia.
(http://www.trecentoundici.com/upload/sip01.jpg)
-
Scusa potresti postare le configurazioni del 3cx?
-
Ci sono appena riuscito.
Con la versione 3CXPhone for 3CX Phone System ver.12.0.5 non c'è verso, invece ho installato la ver.3.0.41 (penso sia più recente) e con quella funziona finalmente!!
Gli unici dati che ho inerito creando un account nuovo sono:
Name: OSO LX Shop
Display name: 145
User: 145
ID: 145
Password: 123456
LocalPBX IP: 172.20.20.55
Tutto il resto default e ora funziona.
Thanks!
-
E' bello e comodo ma sono più le volte che si inchioda o dopo la risposta il client rimane in Calling inchiodato..
Oltre al fatto che appena uso il tasto "Hold" su Client 3CX per iPhone mette in attesa e crasha la App, appena lo riapri la chiamata non si riesce più a raggiungere facendo rimanere il cliente in attesa per tutta l'eternità.
Non esistono software Siemens/Unify, o qualcosa di certificato e funzionante per poter dare un telefono tramite client SIP a chi un telefono fisso non ce l'ha? Grazie ancora.
Gen.
-
Ciao,
prova il Media5- fone. Funziona bene.
http://wiki.unify.com/images/archive/1/10/20120626150825!Configuration_Media5-fone.pdf
-
Buongiorno e BUON ANNO a tutti.
Torno su questo post dopo aver tralasciato il discorso per circa un mesetto.
Maistrak: grazie Media5-fone l'ho provato e funziona bene!
Alessandro Telcom: non riesco ad installare Wireshark su SLES11.
Se scarico il pacchetto tar.bz2, lo estraggo e lo installo con ./configure mi restituisce questo errore.
(http://www.trecentoundici.com/upload/wireshark_error.JPG)
Invece per quanto riguarda l'RPM lo trovo già nella versione o devo scaricarlo? Non lo trovo assolutamente da nessuna parte online, esiste tutto solo per openSuSE e non SuSE Linux.
Zypper lo posso utilizzare soltanto con l'RPM? Come devo fare? (lo trovo in YAST2 ma non so come si utilizza, e sopratutto non trovo l'rpm).
Grazie e buon lavoro a tutti
G.
-
Dovresti usare YAST2 per installare Wireshark (ovviamente presente nei Repositories ai quali fa riferimento SuSE Enterprise Linux 11, vedi infatti qui (https://www.suse.com/LinuxPackages/packageRouter.jsp?product=server&version=11&service_pack=&architecture=i386&package_name=wireshark)).
Per familiarizzare con YAST2 (nota l'acronimo: Yust Another Setup Tool...), che è un gestore di pacchetti il cui scopo è renderti la vita più facile con la gestione delle dipendenze dei pacchetti (oltre a fare centinaia di altre cose utili), prova a leggere qui (http://it.opensuse.org/YaST_Software_Management) (in Italiano).
Se intendi proseguire sulla strada dell'installazione partendo da un pacchetto sorgente devi preoccuparti prima della risoluzione (a mano o usando un gestore di pacchetti come YAST2) delle relative inter-dipendenze (se il pacchetto A richiede la presenza di B devi prima installare B e poi A...sempre che la catena si fermi qui): ecco perchè si "tende" ad usare un gestore di pacchetti facendo attenzione a che repositories (soprattutto nel caso di Server) si vanno ad abilitare.
Saluti, Kimera.