Torsten Posted December 11, 2014 #1 Share Posted December 11, 2014 Hallo Forengemeinde, aktuell kämpfen wir bei einem Kunden mit Sprachproblemen und das stellt sich wie folgt dar: Während eines Gespräches kommt es zu stimmlichen Verzerrungen bis hin zu kurzzeitigen Ausfällen, das Gespräch selbst bleibt aber verbunden.Mal sind es nur wenige Verzerrungen, mal mehr. Aktuell sind wir auf dem Stand, dass nur das Patton-Gateway die Fehlerquelle sein kann und die Probleme über einen Zeitraum von 2-3 Wochen schlimmer werden. Es verhält sich so, dass unser Kunde anruft und sich über die Gesprächsquallität beschwert, wir reseten (powercycle) den Patton und nachweislich ist danach die Gesprächsqualität wieder in Ordnung. Dann baut sich das Ganze in 2-3 Wochen auf. Am Anfang sind es nur wenige Sprachprobleme und jeder schaut drüber hinweg. Mit der Zeit werden die Probleme größer und der Anrufer/Angerufene unseres Kunden meldet Sprachprobleme. Wie kommen wir auf den Patton? Wir setzen bei unserem Kunden eine Swyx 2013 R5 ein. Alle lokalen Rechner dienen als ThinClients für den TerminalServer. Auf den ThinClients (Fujitsu PC) ist der SwyxIT-Client 2013 R5 installiert und ein Jabra-Headset USB inkl. Jabra Suite (notwendig wegen "onhook" und Rufannahme). Auf dem TerminalServer wiederum ist auch ein SwyxIt 2013 R5 installiert und steuert den lokalen SwyxIt per CTI. Fast alle nutzen diese Konstellation, wir haben aber auch ein IP-Telefon und 2 Handsets (USB) in Betrieb.Am Anfang gingen wir noch davon aus, dass es irgendwie mit den lokalen Clients/Headsets zu tun hat (...das Problem ist auch relativ schlecht reproduzierbar, da wir nicht jeden Tag mit dem Kunden zu Testzwecken telefonieren können..), denn wir bekamen die Aussage, dass das IP-Telefon und die Handsets keine Probleme machen. Genau heute konnte ich feststellen, dass auch diese Geräte die gleiche Art von Sprachstörungen haben. Also Patton neu gestartet und alles ist wieder in Butter. Den Patton hatten wir bereits vor 4-5 Wochen getauscht und sind auch schon an unseren Support-Partner heran getreten. Hier hieß es ganz klar -> Update neues Release und Wireshark. Sprich, man kann uns hier nicht wirklich helfen. Auch die NTBA's wurden bereits geprüft, alles OK. Auch zum Thema Erdung habe wir Schritte unternommen, übrigens ein sehr wichtiges Thema.Des Weiteren haben wir in dieser Art und Weise auch bei zwei weiteren Kunden Swyx 2013 Anlagen am laufen und hier gibt es keinerlei Probleme, außer dass hier nur IP-Telefone betrieben werden. Wie bereits geschrieben funktioniert nach eine Patton-Neustart alles wieder und wir sind mit unserem Latein vollkommen am Ende.Hat jemand von euch ein solches Phänomen schon gehabt, oder wie würdet ihr an ein solches Thema herangehen? PS: Das Thema mit den Logfiles und/oder Wireshark ist sehr schwierig, da das Problem eben nur sporadisch auftritt.... vG und DankeTorsten Schmidt Link to comment Share on other sites More sharing options...
Torsten Posted December 11, 2014 Author #2 Share Posted December 11, 2014 Nachtrag: Es handelt sich um eine Patton Mediagateway SmartNode 4638 Link to comment Share on other sites More sharing options...
tip Posted December 16, 2014 #3 Share Posted December 16, 2014 Hast du die letzte Firmware SmartWare 6.6 Build Series 2014-09-03 drauf? Wenn nicht bitte unbedingt updaten, es gab hier definitv ein Patton Problem in Verbindung mit der Swyx und zwar über mehrere Versionen hinweg, da hat sich dann hochgeschaukelt. Seit der angegeben Firmware ist das gefixt und passiert auch nicht mehr... SGStefan Link to comment Share on other sites More sharing options...
Torsten Posted December 16, 2014 Author #4 Share Posted December 16, 2014 Hallo Stefan, vielen Dank für den Tipp. Ich hatte bisher ein Firmware-Update nicht in Betracht gezogen, da es bei den anderen Kunden je funktionierte. Ist aber sicherlich notwendig, ...auch für eine Supportanfrage an Patton.Allerdings wird es vermutlich 1-2 Wochen dauern, bis ich dazu komme. Ich melde mich wieder. vG Torsten Link to comment Share on other sites More sharing options...
Torsten Posted January 2, 2015 Author #5 Share Posted January 2, 2015 Hallo, auch unser Reseller-Support verweist auf das Firmware-Update vom September 2014, damit soll das Problem behoben sein.Ich hatte das Firmware-Update vor Weihnachten eingespielt (verlief völlig unproblematisch) und gehe davon aus, dass ich bis Ende Januar weiß, ob das Problem behoben ist. Siehe hierzu auch folgenden Artikel:http://www.swyx.de/produkte/support/wissensdatenbank/artikel-details/swyxknowledge/kb4549 vGTorsten Link to comment Share on other sites More sharing options...
Torsten Posted January 22, 2015 Author #6 Share Posted January 22, 2015 Hallo, wie versprochen, hier das Feedback zum Update: Seit dem Update gibt es keine Sprachprobleme mehr :-) vGTorsten Link to comment Share on other sites More sharing options...
Torsten Posted June 18, 2015 Author #7 Share Posted June 18, 2015 Hallo, ein kleiner Nachtrag zu dem Thema.Leider hat sich schlussendlich herausgestellt, dass trotz Firmware-Update das Problem nicht behoben wurde.Immer noch gab es nach 2-3 Wochen Sprachprobleme.Nachdem ein Neustart des Patton das Problem behob, gab es zwei Möglichkeiten:Eine Zeitschaltuhr einzubauen ;-) oder aber nach einer anderen Möglichkeit zu suchen. Unser Reseller-Support gab uns hier die Möglichkeit, den Patton mittels Task direkt auf dem Gerät wöchentlich neu zu starten.Auch wenn dies nicht wirklich die beste Lösung ist, da das eigentliche Problem damit nicht behoben wurde, haben wir uns dafür entschieden.Zu tun ist am Patton folgendes: Vatiante1 per putty oder telnet einloggenenableconfigureund jeweils mit enter bestaetigen.Anschliessend diesen Text einfuegen:timer RELOAD jan 1st 2000 previous sunday every week "reload forced"exitexitexitund jeweils mit enter bestaetigen. Oder 2. ueber die Weboberflaeche die RunningConfig exportierendie Aenderungen einpflegen, das sieht dann insgesamt so aus:....cli version 3.20clock local default-offset +02:00clock local dst-rule DST +01:00 from 03:00 oct 31st previous sunday until 02:00 mar 31st previous sundaytimer PROVISIONING now + 3 minutes "provisioning execute PF_PROVISIONING_CONFIG"timer RELOAD jan 1st 2000 previous sunday every week "reload forced"..... Link to comment Share on other sites More sharing options...
Most Valued User Dustie Posted June 19, 2015 Most Valued User #8 Share Posted June 19, 2015 Hi, ich hab die gleichen Fehler bei einer Swyxware2013R2 und einer SwyxConnect 8084.Gleiches Verhalten wie bei dir.Auch hier wurde alles getauscht incl. des Providers, War zum Schluss so das täglich der Fehler aufgetaucht ist.Auch hier hat nur ein Neustart geholfen.Um da ruhe rein zubringen habe ich ein abgesetztes Gateway auf eine alten Pc installiert.Danach war der Fehler weg. Das läuft jetzt erstmal.Nach meinem Urlaub werde ich das ganze Stück für Stück zurückbauen und testen woher der Fehler kommt.Was meintes du mit Thema Erdung ist wichtig? Hat das was gebracht ? Gruß Dustie Link to comment Share on other sites More sharing options...
Torsten Posted June 19, 2015 Author #9 Share Posted June 19, 2015 Hallo Dustie, gebracht hat das Thema Erdung in diesem Fall nichts. Nachdem das Thema beim Kunden nun aber seit über einem Jahr lief, haben wir uns an jeden Strohhalm geklammert. Ich bin leider kein Elektrotechniker. 2 meiner Kollegen hatten vor längerer Zeit ein sehr tiefgreifendes Gespräch mit einem "Elektro-Fachmann" der auch Firmen zu dem Thema berät.Ich versuche es mal laienhaft wiederzugeben:Final geht es um Fehlerströme die Auswirkungen auf die Qualität des Netzwerkverkehrs haben "können". Wir sorgen mit einer Erdung des Patchpanels und des Racks dafür, dass diese Fehlerströme nicht über das Cat-Kabel abgeleitet werden, sondern über ein spezielles Erdungskabel (großerQuerschnitt) der Hauserde zugeführt und somit abgeleitet werden. Damit bleiben die Cat-Kabel von Störungen verschont.Ob es jetzt tatsächlich Voodoo ist oder ob das was bringt, ich weiß es nicht und habe keine Ahnung davon ;-) Laut meine Kollegen klang es sehr plausibel und konnte mit Messungen bewiesen werden. @allBitte jetzt nicht diesen Threat für Antworten zu meiner Aussage zum Thema Erdung mißbrauchen, dass hat hier nicht zu suchen :-) Link to comment Share on other sites More sharing options...
Most Valued User srom Posted June 19, 2015 Most Valued User #10 Share Posted June 19, 2015 Zum Thema Erdung, es ist Pflicht und sollte aus Eigensicherung durchgeführt werden.Es gab schon etliche Schränke mit Strom drauf, was auch hätte gefährlich ausgehen können. Link to comment Share on other sites More sharing options...
Most Valued User Virikas Posted June 23, 2015 Most Valued User #11 Share Posted June 23, 2015 Dazu hab ich ein aktuelles Beispiel eines 24-Port ATAs der partout nicht faxen wollte. Die Erdung hing zwar am Schrank, aber der Schrank selbst war nicht geerdet. Nachdem das korrekt verkabelt war, war alles vorbei. Soooo Voodoomäßig ist das also gar nicht. Und Brummschleifen im HiFI Breich kennt ja denke ich auch jeder BTT: Hattet ihr hier mal einschränken können ob die Fehler auf der ISDN Seite oder der SIP Seite auftreten? Ersteres könnte man z.B. mit einem internen S0 Telefon direkt am Mediagateway testen, sofern die Anschlüße das hergeben. Letzteres braucht halt immer einen Wireshark von einem 100% betroffenen Gespräch. Link to comment Share on other sites More sharing options...
Torsten Posted June 24, 2015 Author #12 Share Posted June 24, 2015 Hallo Virikas, ISDN konnten wir nur soweit ausschließen, dass die NTBA's komplett ausgesteckt wurden und das Problem immer noch bestand. Mit ISDN-Telefon wäre vielleicht eine Möglichkeit gewesen, aber....Das Problem ist ja immer schlimmer geworden und war trotzdem schwer reproduzierbar. Ein Techniker ans Telefon stellen und warten bis was passiert, naja...Des Weiteren mussten wir zwangsweise schon zuvor, wenn sich die Störungen Stück für Stück angekündigt haben, den Patton neu starten um den Kunden nicht zu verärgern. Ich kann ihn ja schlecht bitte, bis zum Gau zu warten. vGTorsten Link to comment Share on other sites More sharing options...
Most Valued User Virikas Posted June 25, 2015 Most Valued User #13 Share Posted June 25, 2015 ISDN konnten wir nur soweit ausschließen, dass die NTBA's komplett ausgesteckt wurden *verwirrt* Wie habt ihr denn dann noch telefoniert? Anscheinend verstehe ich das Rufszenario hier dann vollkommen falsch. Ich war bisher davon ausgegangen, dass es sich um _externe_ Gespräche handelt. Link to comment Share on other sites More sharing options...
Torsten Posted June 30, 2015 Author #14 Share Posted June 30, 2015 Hallo Virikas, wir haben nur kurzfristig die ISDN-Kabel gezogen um den ISDN-Bus neuzustarten (Anweisung vom Support) bzw. diesen auszuschließen.Ob es jetzt tatsächlich ein ISDN-Problem oder Patton-Problem ist, werden wir anscheinend nie wirklich erfahren.Nachdem aber ein Reboot des Patton hilft und dieser automatisch neu gestartet werden kann, sollten wir das Thema jetzt ruhen lassen. vGTorsten Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.