4
Sporadische Stoerungen, einen voip-Trace debuggen, Raum FRA
Hallo @all,
ich wende mich jetzt an das Forum, weil auch easybell (eb) eine sehr duerftige Aussage lieferte.
Ich brauche jemanden, der im Raum FRA, best of in Frankfurt a. Main selbst unterwegs ist und mir beim Debug eines/mehrerer Traces gegen gutes Geld der voip-Daten helfen kann manche Stoerungen zu identifizieren oder auch nur zu belegen, dass intern keine Probleme sind.
Vorab die Beschreibung des Problems:
Eine freepbx x.y.z in virt. Umgebung auf debian Server lief knapp drei, zwei Jahre produktiv ohne einzigen Fehler, es funktionierte einfach 100 Prozent. Weder waren Abrisse noch Stoerungen das Problem, gaaaar nix. Wie geht sowas? Es war moeglich. Seit 08/09.2021 wurden v. den Benutzern Stoerungen gemeldet, so wie es ist mit den Steoerungen sind, natuerlich nicht konstant sondern sporadisch, eben nur manche Anrufe.
Die Stoerungen sind folgendermassen klassifiziert:
Sofern man eine nicht unterdrueckte CLIP hat, sieht, loest ein Rueckruf alle Probleme, keine Abrisse, keine Schwierigkeiten insgesamt.
Sprich bei ausgehenden Anrufen (auf einem trunk, es sind zwei Trunks) gibt es ___keine___ Probleme. Es sind _immer_ eingehende Anrufe betroffen. Eine int. Untersuchung ueber mehrere Wochen konnte belegen, dass viel mehr Mobiltel.-rufe v. extern das Problem darstellen, ebenso unter diesen Stoerungen 0176 fuehrend ist.
Als house keeping habe ich folgendes umgesetzt um den Fehler einzukreisen. Em Ende sind doch noch Stoerungen, die die taegliche Arbeit laut den Angaben der Benutzer doch massiv einschraenken.
eb hatte im Sommer eine Umstellung von sip.easybell auf voip.easybell. Die int. freepbx hat diese Umstellung ohne Kopfschmerzen mitgemacht, damals war vor/nach der Umstellung kein Unterschied. Die Umstellung erfolgte 07.2021. Diese Configaenderung ist also nicht das Problem.
Ich habe die int. virt. voip-TA aus einer Sicherung rueckgespielt, eine komplette Sicherung des raw-Images. Dieses Image war v. 07.2021, also weit vor den Stoerungen. Es half nicht die Stoerung zu eliminieren.
Diese rueckgesicherte Anlage lief auf einer __anderen__ HW (C910 Fujitsu). D.h. die NIC, als auch das BS, als auch der Switch(port) waeren so nicht mehr im Fokus. Die org. Anlage ist auf einem HP ML 350 G6. D. h. weder ein Image-Wechsel der freepbx, noch ein HW/NIC Wechsel haben eine Besserung gebracht.
Die voip-TA und die Voip-HW laufen auf einem VLAN, aqui wird hier die Haende ueber den Kopf schlagen
auf HP-Switches.
An diesen Switches haengt das ganze LAN, die Server, das Admin-Netz, das WLAN etc. Ebenso haengt dort mit vier NICs (Intel) eine pfsense.
Der Laden ist per fixer IP bei UnityMedia, Coax angebunden (5er IP-Block), eine Alternative ist ein DSL (noch langsamer Anschluss, 13/1,3, bald 250/40) Anschluss.
Die pfsense macht den Hauptjob, der DSL Anschuss ueber eine FBox 7590 ist fuer das Fax (auch bei eb) als auf fuer einen best. Tunnel notwendig. Und notwendig, wenn UM mal wieder Ausfaelle hat, dann erfolgt auto-routing auf DSL.
Ich habe nirgends eine Stoerung, weder OpenVPN-Zugaenge, noch wg, noch ssh/scp haben Probleme, so dass ich annehme, dass die FW nicht die Pakete zerhackt. An der Konfig der pfsense ist im Betrieb (vor/nach den Steorungen) auch keine Veraenderung erfolgt.
Da ich fast alle int. Felder abgehakt hatte, habe ich die Stoerungen mit der Bitte der Rueckverfolgung der gestoerten Telephonate an eb gesandt. Das Ergebnis ist:
Die Verbindung war Daten bidirectional(Audio in beide Richtungen) und es bestand kein Paketverlust im gesamten Anruf bei jedem Streckenabschnitt.
rtp-direction: bidirectional
rtp-lossavg: 0
rtp-lossmax: 0.0
gaps\":\"0\", \"lost_percentage\":\"0.0\", \"jitter\":\"0\", \"dropped\":\"0
Wir vermuten derzeit, dass die Störungen von Ihrem Endgerät (Router oder Telefon) oder im Netzwerk verursacht werden.
So ansich ist das eine tolle Aussage, NULL Fehler. Und doch ...
Es gibt __keinen__ Paketverlust, und doch sollen die Probleme am Router/Telefon oder im LAN sein. Wow. Da die Yealinks 48s (3x) alle diese Stoerungen haben (Anrufe kommen dort rein), koennen wir die Tischtel. aus dem Spiel nehmen, alle drei defekt, auf einmal?
Ein check-the-cables-Proeblem hatten wir auch, gefunden und geloest, defekte Hoererkabel. Jetzt nach dem Austausch sind immer noch gestoerte Gespraeche.
Wobei ich wahrlich nicht nachvollziehen kann wie __keine__ Paketverluste als auch NULL-Paketfehler festgestellt werden, aber die int. HW in irgendeiner Form doch Probleme macht, so das am Ende (ohne einen Paketverlust(sic)) das Gespraech gestoert ist. Der Logik nach muss es der Swich und/oder die pfsense sein. Alles andere ist abgehakt. Aber beide Switches gelichzeitig defekt, beide zur selben Zeit?
Die pfsense auf HW habe ich _nicht_ ausgetauscht. Die koennte theoretisch noch das Problem darstellen, jedoch alles andere funkt einwandfrei und unauffaellig, so dass ich annehme (nicht belegen kann), dass auch diese HW OK ist.
Sprich, ich bin mit dem Latein am Ende, wo der Hund begraben ist.
Gerne nehme ich jegliche Hilfe an, wenn mehr Daten gefordert sind, pls. reply, was fehlt. Dies war eine Uebersicht, Zusammenfassung. ohne tech. Details, denn die Anlage hat zwei Jahre, ohne Nix einwandfrei funktioniert, eine Configaenderung im LAN/oder den devices erfolgte nicht, never touch a running system.
Oder, wenn jemand mir Kontaktadressen fuer faehige Leute, die das Proeblem sniffern koennen nennt, waere ich auch dankbar. Es wird hier klar offiziell und fair bezahlt, umsonst soll niemand arbeiten. Das Problem nervt, alles (bís auf FW Tausch und voip ueber FBox/DSL) ist int. abgeklaert, doch es sind noch Stoerungen da, der Unmut wird groesser.
Danke Euch vorab
ELindemann
ich wende mich jetzt an das Forum, weil auch easybell (eb) eine sehr duerftige Aussage lieferte.
Ich brauche jemanden, der im Raum FRA, best of in Frankfurt a. Main selbst unterwegs ist und mir beim Debug eines/mehrerer Traces gegen gutes Geld der voip-Daten helfen kann manche Stoerungen zu identifizieren oder auch nur zu belegen, dass intern keine Probleme sind.
Vorab die Beschreibung des Problems:
Eine freepbx x.y.z in virt. Umgebung auf debian Server lief knapp drei, zwei Jahre produktiv ohne einzigen Fehler, es funktionierte einfach 100 Prozent. Weder waren Abrisse noch Stoerungen das Problem, gaaaar nix. Wie geht sowas? Es war moeglich. Seit 08/09.2021 wurden v. den Benutzern Stoerungen gemeldet, so wie es ist mit den Steoerungen sind, natuerlich nicht konstant sondern sporadisch, eben nur manche Anrufe.
Die Stoerungen sind folgendermassen klassifiziert:
- der externe Anrufer hoert den Benutzer nicht, ein Rueckruf loest das Problem, das Gespraech reisst nicht ab, die Sprachqualitaet ist gut/sehr gut, verstaendlich.
- der externe Anrufer wird nicht gehoert
- einfacher Abbruch
Sofern man eine nicht unterdrueckte CLIP hat, sieht, loest ein Rueckruf alle Probleme, keine Abrisse, keine Schwierigkeiten insgesamt.
Sprich bei ausgehenden Anrufen (auf einem trunk, es sind zwei Trunks) gibt es ___keine___ Probleme. Es sind _immer_ eingehende Anrufe betroffen. Eine int. Untersuchung ueber mehrere Wochen konnte belegen, dass viel mehr Mobiltel.-rufe v. extern das Problem darstellen, ebenso unter diesen Stoerungen 0176 fuehrend ist.
Als house keeping habe ich folgendes umgesetzt um den Fehler einzukreisen. Em Ende sind doch noch Stoerungen, die die taegliche Arbeit laut den Angaben der Benutzer doch massiv einschraenken.
eb hatte im Sommer eine Umstellung von sip.easybell auf voip.easybell. Die int. freepbx hat diese Umstellung ohne Kopfschmerzen mitgemacht, damals war vor/nach der Umstellung kein Unterschied. Die Umstellung erfolgte 07.2021. Diese Configaenderung ist also nicht das Problem.
Ich habe die int. virt. voip-TA aus einer Sicherung rueckgespielt, eine komplette Sicherung des raw-Images. Dieses Image war v. 07.2021, also weit vor den Stoerungen. Es half nicht die Stoerung zu eliminieren.
Diese rueckgesicherte Anlage lief auf einer __anderen__ HW (C910 Fujitsu). D.h. die NIC, als auch das BS, als auch der Switch(port) waeren so nicht mehr im Fokus. Die org. Anlage ist auf einem HP ML 350 G6. D. h. weder ein Image-Wechsel der freepbx, noch ein HW/NIC Wechsel haben eine Besserung gebracht.
Die voip-TA und die Voip-HW laufen auf einem VLAN, aqui wird hier die Haende ueber den Kopf schlagen
auf HP-Switches.An diesen Switches haengt das ganze LAN, die Server, das Admin-Netz, das WLAN etc. Ebenso haengt dort mit vier NICs (Intel) eine pfsense.
Der Laden ist per fixer IP bei UnityMedia, Coax angebunden (5er IP-Block), eine Alternative ist ein DSL (noch langsamer Anschluss, 13/1,3, bald 250/40) Anschluss.
Die pfsense macht den Hauptjob, der DSL Anschuss ueber eine FBox 7590 ist fuer das Fax (auch bei eb) als auf fuer einen best. Tunnel notwendig. Und notwendig, wenn UM mal wieder Ausfaelle hat, dann erfolgt auto-routing auf DSL.
Ich habe nirgends eine Stoerung, weder OpenVPN-Zugaenge, noch wg, noch ssh/scp haben Probleme, so dass ich annehme, dass die FW nicht die Pakete zerhackt. An der Konfig der pfsense ist im Betrieb (vor/nach den Steorungen) auch keine Veraenderung erfolgt.
Da ich fast alle int. Felder abgehakt hatte, habe ich die Stoerungen mit der Bitte der Rueckverfolgung der gestoerten Telephonate an eb gesandt. Das Ergebnis ist:
Die Verbindung war Daten bidirectional(Audio in beide Richtungen) und es bestand kein Paketverlust im gesamten Anruf bei jedem Streckenabschnitt.
rtp-direction: bidirectional
rtp-lossavg: 0
rtp-lossmax: 0.0
gaps\":\"0\", \"lost_percentage\":\"0.0\", \"jitter\":\"0\", \"dropped\":\"0
Wir vermuten derzeit, dass die Störungen von Ihrem Endgerät (Router oder Telefon) oder im Netzwerk verursacht werden.
So ansich ist das eine tolle Aussage, NULL Fehler. Und doch ...
Es gibt __keinen__ Paketverlust, und doch sollen die Probleme am Router/Telefon oder im LAN sein. Wow. Da die Yealinks 48s (3x) alle diese Stoerungen haben (Anrufe kommen dort rein), koennen wir die Tischtel. aus dem Spiel nehmen, alle drei defekt, auf einmal?
Ein check-the-cables-Proeblem hatten wir auch, gefunden und geloest, defekte Hoererkabel. Jetzt nach dem Austausch sind immer noch gestoerte Gespraeche.
Wobei ich wahrlich nicht nachvollziehen kann wie __keine__ Paketverluste als auch NULL-Paketfehler festgestellt werden, aber die int. HW in irgendeiner Form doch Probleme macht, so das am Ende (ohne einen Paketverlust(sic)) das Gespraech gestoert ist. Der Logik nach muss es der Swich und/oder die pfsense sein. Alles andere ist abgehakt. Aber beide Switches gelichzeitig defekt, beide zur selben Zeit?
Die pfsense auf HW habe ich _nicht_ ausgetauscht. Die koennte theoretisch noch das Problem darstellen, jedoch alles andere funkt einwandfrei und unauffaellig, so dass ich annehme (nicht belegen kann), dass auch diese HW OK ist.
Sprich, ich bin mit dem Latein am Ende, wo der Hund begraben ist.
Gerne nehme ich jegliche Hilfe an, wenn mehr Daten gefordert sind, pls. reply, was fehlt. Dies war eine Uebersicht, Zusammenfassung. ohne tech. Details, denn die Anlage hat zwei Jahre, ohne Nix einwandfrei funktioniert, eine Configaenderung im LAN/oder den devices erfolgte nicht, never touch a running system.
Oder, wenn jemand mir Kontaktadressen fuer faehige Leute, die das Proeblem sniffern koennen nennt, waere ich auch dankbar. Es wird hier klar offiziell und fair bezahlt, umsonst soll niemand arbeiten. Das Problem nervt, alles (bís auf FW Tausch und voip ueber FBox/DSL) ist int. abgeklaert, doch es sind noch Stoerungen da, der Unmut wird groesser.
Danke Euch vorab
ELindemann
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2333659054
Url: https://administrator.de/forum/sporadische-stoerungen-einen-voip-trace-debuggen-raum-fra-2333659054.html
Ausgedruckt am: 19.04.2025 um 06:04 Uhr
4 Kommentare
Neuester Kommentar
Hallo,
keine Lösung und kein Angebot.
Nur eine Info.
Kunden von mit mit NFON hatten in den letzten Jahren schon 3 Carrier-Probleme.
z.B. konnte man von Vodafone manchmal nicht anrufen oder wurde nicht gehört.
Das war immer ziemlich fummelig dies mit Beispielen (Uhrzeit, Datum, Rufnummern) zu dokumentieren und von NFON prüfen zu lassen. Meist hat es 3-4 Versuchen und mehrere Tage gedauert. In allen Fällen war das Problem auf ein Netzwerkproblem bei einem Carrier zurückzuführen.
Stefan
keine Lösung und kein Angebot.
Nur eine Info.
Kunden von mit mit NFON hatten in den letzten Jahren schon 3 Carrier-Probleme.
z.B. konnte man von Vodafone manchmal nicht anrufen oder wurde nicht gehört.
Das war immer ziemlich fummelig dies mit Beispielen (Uhrzeit, Datum, Rufnummern) zu dokumentieren und von NFON prüfen zu lassen. Meist hat es 3-4 Versuchen und mehrere Tage gedauert. In allen Fällen war das Problem auf ein Netzwerkproblem bei einem Carrier zurückzuführen.
Stefan
Moin,
Du nimmst etwas schnell die beteiligten "Gerätschaften" aus dem Spiel. Auch wenn keine Konfigurationsänderung vorgenommen wurde, heisst das ja noch nicht, dass es korrekt konfiguriert war/ist.
Was allgemein etwas auffällt, es kommt recht alte Hardware zum Einsatz (der HP Gen6 Server, der Ersatz Fujitsu C610).
Welche Switche kommen denn genau zum Einsatz, welcher Hypervisor und welche Version der FreePBX (die aber allgemein einen recht unregelmäßigen Updatezyklus hat)?
An dem Trace von Easybell ist soweit nichts auszusetzen, das ist alles, was sie sehen/prüfen können. Der Rest liegt bei anderen Carriern und den jeweiligen Endpunkten (Deine Seite und die des Anrufers/Angerufenen).
Ist denn auf Deiner Seite QoS für VoIP sauber konfiguriert? Könnte auch ein Problem mit fehlerhafter Codec-Aushandlung beim Gesprächsaufbau sein und/oder ein Bug in der verwendeten Firmware der Yealink-Telefone.
Ggf. mal testweise ein Softphone für eine Weile einsetzen (PhonerLite o.ä.) zur Gegenprobe.
Zur Fehlerursache wären sehr zeit- und kostenaufwändige Analysen notwendig, da ist es nicht mit ein paar Traces getan.
Ist auf jeden Fall nicht mal eben so in der Mittagspause gelöst, was ist z.B. wenn der Fehler jetzt für x Wochen nicht mehr auftritt?
Und zum Phänomen mit dem (sofort) funktionierenden Rückruf ist ebenfalls auf die verwendeten Carrier zurückzuführen, genaueres Beispiel:
- Anrufer ruft von seinem Mobiltelefon auf eurer Nummer an -> Mobilprovider entscheidet das weitergehende Anrufrouting zu Easybell -> Carrier 1 -> Carrier 2 -> Easybell Netz (ich meine, das wäre noch bei QSC?) -> Euer Anschluss
- Rückruf auf Mobilnummer des Anrufers, Anrufrouting durch Easybell -> Carrier 3 -> Carrier 4 -> (Mobilnetz des Anrufers) -> Anschluss des Anrufers
und so könnte ich weitere Beispiele auflisten ...
Gruß
cykes
Du nimmst etwas schnell die beteiligten "Gerätschaften" aus dem Spiel. Auch wenn keine Konfigurationsänderung vorgenommen wurde, heisst das ja noch nicht, dass es korrekt konfiguriert war/ist.
Was allgemein etwas auffällt, es kommt recht alte Hardware zum Einsatz (der HP Gen6 Server, der Ersatz Fujitsu C610).
Welche Switche kommen denn genau zum Einsatz, welcher Hypervisor und welche Version der FreePBX (die aber allgemein einen recht unregelmäßigen Updatezyklus hat)?
An dem Trace von Easybell ist soweit nichts auszusetzen, das ist alles, was sie sehen/prüfen können. Der Rest liegt bei anderen Carriern und den jeweiligen Endpunkten (Deine Seite und die des Anrufers/Angerufenen).
Ist denn auf Deiner Seite QoS für VoIP sauber konfiguriert? Könnte auch ein Problem mit fehlerhafter Codec-Aushandlung beim Gesprächsaufbau sein und/oder ein Bug in der verwendeten Firmware der Yealink-Telefone.
Ggf. mal testweise ein Softphone für eine Weile einsetzen (PhonerLite o.ä.) zur Gegenprobe.
Zur Fehlerursache wären sehr zeit- und kostenaufwändige Analysen notwendig, da ist es nicht mit ein paar Traces getan.
Ist auf jeden Fall nicht mal eben so in der Mittagspause gelöst, was ist z.B. wenn der Fehler jetzt für x Wochen nicht mehr auftritt?
Und zum Phänomen mit dem (sofort) funktionierenden Rückruf ist ebenfalls auf die verwendeten Carrier zurückzuführen, genaueres Beispiel:
- Anrufer ruft von seinem Mobiltelefon auf eurer Nummer an -> Mobilprovider entscheidet das weitergehende Anrufrouting zu Easybell -> Carrier 1 -> Carrier 2 -> Easybell Netz (ich meine, das wäre noch bei QSC?) -> Euer Anschluss
- Rückruf auf Mobilnummer des Anrufers, Anrufrouting durch Easybell -> Carrier 3 -> Carrier 4 -> (Mobilnetz des Anrufers) -> Anschluss des Anrufers
und so könnte ich weitere Beispiele auflisten ...
Gruß
cykes
Hallo cykes,
danke fuer die Rueckmeldung. Gleich zu Beginn dachte ich mir, dass es aufwendig wird, doch die Betroffenen Benutzer und Chefs sind nicht sehr compliant. Sie duerfen das, doch so kommt man auch nicht voran.
@geraetschaften: Du hast REcht, alte Switches, alte HW (C910 != C610), doch eben gerade mit dem Tausch untereinander etc. konte ich die lage nicht verbessern. Sprich, egal welche HW (nicht alle gehen z. identischer Zeit kaputt) es bleibt. Einzig, die Switches und doe PFsense sind noch die alten. Aber alle Zaehler, Paketverluste etc sind auf Null.
Und klar, wenn CarrrierProbelem sind, bin ich out, doch dies kann ich halt nur belegen, wennich intern beweisen kann, dass ich kein LAN (egal welche Komponente habe). UM hat seit paar Jahren immer wieder Probleme, Ausfaelle in der Nacht (gut, dass keine Daten v. LokA nach LokB ge- verschoben werden), ich bekomme das dans smokeping mit, manchmal Abrisse in der Nacht bis zu 20 min.
D.h. nicht, dass UM das Problem darstellt, vllt.
Bevor ich andere adresseire muss ich selbst clean sein. UNd darum wollte ich das ganze auf dem Draht betrachten und auch gerne noch paar andere Sachen aendern und mit Hilfe eines voip-Kundigen den Stream analysieren.
Vllt. (hoffentlich) ist es ein LAN bezogenes Problem, DANN haette ich die Chance einzugreifen, wenn es UM ist, ist game over, oder eb. Das kann ich ja auch nicht belege nur deduktiv behaupten, wahrscheinlich mit Null-Konsequenz.
Ich kann berichten, dass auch diese alte Anlage einwandfrei funktioniert hat, obwohl alt. Dann ab Punkt x passierte was. Und ich denke nicht, dass ich jetzt neue Server und neue HW kaufen muss um das Problem zu erschlagen. Das ist doch dann ein Schrotflintenschuss, in der Hoffnung, dass es passt, trifft.
Wenn ich mit Hilfe eines voip-Protokoll Kundigen den (keine) Fehler sehe bin ich erstmal ein Stck. weiter, anstatt alles in Frage zustellen und alles auszutauschen.
@yl48s, auch kein Update. Wie gesagt, das System *IST* die Konstante, was natuerlich immer gegeben ist, dass eine Komponente defekt wurde, das jedoch sollte ich auf dem Draht sehen, wenn sie Pakete zerhackt, retrys sind, und/oder Auffaelligkeit sind, rsync nicht suaber durchlaueft, weil Daten korrumpiert sind etc. Ich habe da Null Ansatz, weil ich auf diesen Feldern NULL Probleme habe. Egal im LAN, der WAN, wenn ich GB rausschiebe, alles kommt OK an.
Mein Focus ist, ich kann es nur nicht belegen, dass es, wenn das Gesprach v. extern initiiert wird, den Carrier (egal welcher) in VErdacht habe. Ich selbst erfahre diese Problematik ja auch, dass gerade 0176 auf einmal nicht mehr zu hoeren ist, genau wie die o.a. Problematik.
Zudem nach G3 Abschaltung die uebrig gebliebenen Masten staerker unter Last sind, sprich. Erst, wenn ich intern OK bin, kann diese Aussage in den Raum stellen, nicht vorher, das ist aber noch ein Weg zu gehen.
Danke Dir.
ELindemann
danke fuer die Rueckmeldung. Gleich zu Beginn dachte ich mir, dass es aufwendig wird, doch die Betroffenen Benutzer und Chefs sind nicht sehr compliant. Sie duerfen das, doch so kommt man auch nicht voran.
@geraetschaften: Du hast REcht, alte Switches, alte HW (C910 != C610), doch eben gerade mit dem Tausch untereinander etc. konte ich die lage nicht verbessern. Sprich, egal welche HW (nicht alle gehen z. identischer Zeit kaputt) es bleibt. Einzig, die Switches und doe PFsense sind noch die alten. Aber alle Zaehler, Paketverluste etc sind auf Null.
Und klar, wenn CarrrierProbelem sind, bin ich out, doch dies kann ich halt nur belegen, wennich intern beweisen kann, dass ich kein LAN (egal welche Komponente habe). UM hat seit paar Jahren immer wieder Probleme, Ausfaelle in der Nacht (gut, dass keine Daten v. LokA nach LokB ge- verschoben werden), ich bekomme das dans smokeping mit, manchmal Abrisse in der Nacht bis zu 20 min.
D.h. nicht, dass UM das Problem darstellt, vllt.
Bevor ich andere adresseire muss ich selbst clean sein. UNd darum wollte ich das ganze auf dem Draht betrachten und auch gerne noch paar andere Sachen aendern und mit Hilfe eines voip-Kundigen den Stream analysieren.
Vllt. (hoffentlich
) ist es ein LAN bezogenes Problem, DANN haette ich die Chance einzugreifen, wenn es UM ist, ist game over, oder eb. Das kann ich ja auch nicht belege nur deduktiv behaupten, wahrscheinlich mit Null-Konsequenz.Ich kann berichten, dass auch diese alte Anlage einwandfrei funktioniert hat, obwohl alt. Dann ab Punkt x passierte was. Und ich denke nicht, dass ich jetzt neue Server und neue HW kaufen muss um das Problem zu erschlagen. Das ist doch dann ein Schrotflintenschuss, in der Hoffnung, dass es passt, trifft.
Wenn ich mit Hilfe eines voip-Protokoll Kundigen den (keine) Fehler sehe bin ich erstmal ein Stck. weiter, anstatt alles in Frage zustellen und alles auszutauschen.
@yl48s, auch kein Update. Wie gesagt, das System *IST* die Konstante, was natuerlich immer gegeben ist, dass eine Komponente defekt wurde, das jedoch sollte ich auf dem Draht sehen, wenn sie Pakete zerhackt, retrys sind, und/oder Auffaelligkeit sind, rsync nicht suaber durchlaueft, weil Daten korrumpiert sind etc. Ich habe da Null Ansatz, weil ich auf diesen Feldern NULL Probleme habe. Egal im LAN, der WAN, wenn ich GB rausschiebe, alles kommt OK an.
Mein Focus ist, ich kann es nur nicht belegen, dass es, wenn das Gesprach v. extern initiiert wird, den Carrier (egal welcher) in VErdacht habe. Ich selbst erfahre diese Problematik ja auch, dass gerade 0176 auf einmal nicht mehr zu hoeren ist, genau wie die o.a. Problematik.
Zudem nach G3 Abschaltung die uebrig gebliebenen Masten staerker unter Last sind, sprich. Erst, wenn ich intern OK bin, kann diese Aussage in den Raum stellen, nicht vorher, das ist aber noch ein Weg zu gehen.
Danke Dir.
ELindemann
@StefanKittel
Du hast absolut Recht, dass es ein zusatezliches Problem fuer das Personal ist, dass man staendig dokumentiert, das haben wir intern rel. gut hinbekommen, das kann aber nicht die Loesung sein.
Deswegen kann ich auch Aussagen zu 0176 treffen, 43 Porzent der Mobilfunsteorungen sind bei 0176, bei n=1352 Total, n=1052 Mobilfunkgespraeche.
Trotzdem, wie cykes schreibt, paar Sachen, pfsense aus dem Spiel nehmen, den Switch austauschen ist noch todo, beides doch ein sehr grosses Stck. Arbeit. Die pfsense haelt die Show am Laufen, dsl ist zuuuuu langsam. Die Switches sind nicht l/r. belegt nur v. rechts, aber zumindest farbige Kabel, Raumprobleme beim damaligen Serverschrankaufbau. Planungsfehler des Architekten. Sprich, Heidenarbeit. So oder so.
Wenn ich aber im Trace was sehe, dann koennte ich gezielt ansetzen.
Irgendwie sch...lecht.
Danke Dir.
ELindemann
Du hast absolut Recht, dass es ein zusatezliches Problem fuer das Personal ist, dass man staendig dokumentiert, das haben wir intern rel. gut hinbekommen, das kann aber nicht die Loesung sein.
Deswegen kann ich auch Aussagen zu 0176 treffen, 43 Porzent der Mobilfunsteorungen sind bei 0176, bei n=1352 Total, n=1052 Mobilfunkgespraeche.
Trotzdem, wie cykes schreibt, paar Sachen, pfsense aus dem Spiel nehmen, den Switch austauschen ist noch todo, beides doch ein sehr grosses Stck. Arbeit. Die pfsense haelt die Show am Laufen, dsl ist zuuuuu langsam. Die Switches sind nicht l/r. belegt nur v. rechts, aber zumindest farbige Kabel, Raumprobleme beim damaligen Serverschrankaufbau. Planungsfehler des Architekten. Sprich, Heidenarbeit. So oder so.
Wenn ich aber im Trace was sehe, dann koennte ich gezielt ansetzen.
Irgendwie sch...lecht.
Danke Dir.
ELindemann
