Panasonic NCP-500 mit VoIP, ständig Abbrüche

black-avenger

Enthusiast
Thread Starter
Mitglied seit
06.10.2006
Beiträge
4.560
Ort
Ba-Wü & WÜ
Aloahe,

bin solangsam etwas aus der Ruhe, weil ich mich zwischen Telekom und meinem TK-Dienstleister zerreibe.
In der Telefonie gibts seit der (zwangsweisen) Umstellung auf VoIP ständig Verbindungsabbrüche. Einfach Leitung tot, Gespräch beendet. Das tritt leider nicht reproduzierbar auf. Beim einen Gespräch ist alle 20 Sekunden Schluss, beim nächsten ist wieder alles in Ordnung.

Vom Setup her schaut das ganze wie folgt aus: Router ist eine Fritzbox 7390 (wg. S0 ISDN Port), Panasonic NCP-500 als TK Anlage. Die NCP-500 hängt einmal am S0 der Fritzbox, zieht sich darüber "ISDN" fürs Fax, ebenfalls läuft eine weitere der Rufnummern über den S0 und damit über die Fritte mit. Die restlichen Rufnummern laufen über SIP-Trunks / SIP-Gateway, die NCP wählt sich für diese Verbindungen direkt übers Internet bei der Telekom ein. Diese Kanäle nutzen also nicht die S0 ISDN Emulation der Fritzbox.
Für die Verbindungsabbrüche spielt es übrigens keine Rolle, ob das Telefonat nun über den S0 der Fritte oder nicht läuft. Die Abbrüche treten gleichermaßen auf.

Ich kann bei diesen Gesprächen mit Abbrüchen quasi zusehen, wie die CRC-Fehlerrate hoch geht. Alles noch in einem Bereich, wo die Telekom natürlich sagt, dass das kein Problem sei. "Unter 1000 Fehlern pro Minute ist das alles völlig unkritisch." In der Fritte werden die Fehler bei der FritzBox angezeigt, nicht auf Seiten der Vermittlungsstelle.


Ich hab jetzt also die Situation, dass die Telekom mir sagt, es ist alles in Ordnung, sie können nix tun. Mein TK-Dienstleister schaut die Anlage durch und sagt: Alles korrekt konfiguriert, ich finde nix, muss die Telekom sein.


Hat mir irgendwer eine Idee wo man noch ansetzen könnte? Ultima Ratio seitens TK-Dienstleister wäre natürlich die TK-Anlage komplett durch was 'moderneres', möglicherweise von Alcatel, zu ersetzen. Da in diesem Fall aber auch sämtliche Nebenstellen-Apparate ersetzt werden müssten und ein umfassender Umbau hinsichtlich der strukturierten Verkabelung durchgeführt werden müsste um die Nebenstellen ins Netzwerk zu kriegen, ist das eigentlich nur die allerletzte Option. Zumal uns von keiner Seite garantiert werden kann, ob das das Problem behebt.

Eine Idee wäre natürlich, dass mit unserer Anlage und Verbindung tatsächlich alles in Ordnung ist und die Gesprächspartner einfach alle scheiß Leitungen haben und auf deren Seite die Probleme bestehen. Daran hab ich aber irgendwie nur geringen Glauben.

Bräuchte ich nicht den S0 der Fritte, hätte ich die wohl vermutlich mal gegen was anderes getauscht. Aber da die Fritte in der derzeitigen Lösung einfach ein "Teil" der TK-Anlage ist, fällt das raus. Einzige Möglichkeit wäre sie gegen eine 7490 zu ersetzen. Aber ob das was ändert? Ich bezweifle es.

Wenn irgendwer was weiß, wo man evtl ansetzen könnte - immer her damit. Andernfalls werden wohl über Kurz oder Lang doch zig Tausender in eine neue TK-Anlage mit ungewisser Erfolgschance fließen müssen.

Grüße
Thomas

- - - Updated - - -

Ich hab eben mal noch die Fehlerprotokolle der NCP-500 durchforstet. Es gibt keine Protokollierung eines Fehlers während der Ausfälle. Die einzigen "Fehler" im Protokoll sind die bei den nächtlichen Trennungen unseres Internets. Unmittelbar nach der Trennung ist aber auch der ordnungsgemäße Reconnect der Anlage wieder protokolliert.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Hast du die Möglichkeit SIP Telefonie zum Anbieter hin von einem anderen Gerät zu testen? Hast du pcaps aus dem voice Netz, als die Verbindung abgebrochen wird?

Erstmal müsstest Du herausfinden Wer das Gespräch abbaut, also wer das SIP BYE sendet oder ob gar die Telefonanlage einfach auflegt.
 
Möglichkeit zum Test mit einem anderen Gerät besteht leider nicht, die NCP ist das einzige Gerät, das bei uns hier dazu in der Lage ist. Mitschnitte gibts nicht, es ist derzeit auch nicht in einem separaten VLAN, sondern lediglich über QoS alle Verbindungen des Geräts priorisiert.

Das Mitschneiden ist 'ne gute Idee grds... Die Fritzbox kann den Verkehr ja mitschneiden und ich könnte das danach mit Wireshark auswerten. Was mir beim ersten Mitschneiden nur schon auffällt ist, dass die Protokollgröße wohl ordentlich wird, wenn ich bissl mitschneide. Das könnte öde werden, da ich nicht zuverlässig sagen kann wann der Fehler auftritt und wann nicht.

vorhin z.B. ist wieder ein Gespräch mehrfach abgebrochen. Völlig aus dem Nichts. Davor und danach schien es aber ok. CRC Fehler sind bei dem Telefonat jedoch ordentlich rauf gegangen.
Muss mich mal mit meinem TK-Dienstleister unterhalten, ob es die Möglichkeit gibt eben das rauszufinden, von welcher Seite her die Verbindung abbricht. Danke für den Tipp!

Grüße
Thomas

/edit: Ok, auch ohne Unterhaltung mit dem TK-Dienstleister konnte ich in Wireshark sehen, dass ein Goodbye von und zur IP der SIP-Karte in der NCP-500 gesendet wird. Allerdings war das bei dem einen Gespräch das ich mitschneiden konnte ein beiderseitiges Goodbye. Erst von der Gegenseite zu uns, dann von uns zur Gegenseite. Zeitversatz 0,001s oder sowas.

Wenn ich jetzt noch ein Telefonat mit Abbruch erwischen würde, wär ich evtl etwas schlauer. Spannende Sache.


Was müsste ich im Zweifel erwarten, wenn ich einen Verbindungsabbruch mitschneide? Ein nur einseitiges Goodbye nehme ich mal an?
 
Zuletzt bearbeitet:
Ich hatte das Glück einen Verbindungsabbruch mitzuschneiden und hab ihn jetzt mal in Wireshark gepackt. Etwas diffueses Bild für mich, da ich noch nie groß was mit Wireshark gemacht hab. Aber Egal. Ich versuche mal nachzuskizzieren:

17:29:28.7717 - Dest: KyushuMa (nehme an Telekom HW), Source: AVM (meine Fritte); Header: To: Anschlusskennung des Gesprächspartners, From: Unsere Anschlusskennung; STATUS 500: Timeout sending SIP message
17:29:28.7842 - Dest: Fritte, Source: KyushuMa; Header: To:Anschlusskennung des Gesprächspatners, From: Unsere Anschlusskennzung; Request: ACK sip:Anschlusskennung Gesprächspatner
17:29:28.7866 - Dest: Fritte, Source: KyushuMa; Sender Report Source description Goodbye; Packet Type Goodbye (203)


So... das dürfte wenn ich mich nicht täusche der Verbindungsabbruch gewesen sein. Seh ich das richtig, dass mein Paket nicht raus kommt, dadurch Timeout und die Gegenseite dann deswegen auflegt?

Grüße
Thomas
 
Da als Destination die FB drin steht geh ich mal davon aus daß das über den Kanal auf dem S0 lief? Eigentlich gehört sich da ja die Anlage hin und nicht die FB, wenn die die Nummer registriert. Kannst du keinen Mitschnitt direkt von der Panasonic machen? Bei Unify kannst du das direkt von der Anlage mitschneiden. Da kann ich dir auf jeden Fall aus Erfahrung sagen, das die FB das nicht schafft wenn das über den S0 läuft. Wobei für mich ehrlich gesagt immer noch nicht klar ist warum du den überhaupt in Betrieb hast, bzw wofür beim Fax. Ob die Umwandlung von SIP auf Analog jetzt in der FB stattfindet oder in der TK ist ja an sich eigentlich egal. Wobei ich da der TK noch etwas mehr vertrauen würde :d

Rein vom Trace her würde ich jetzt auch sagen das der gar nicht erst zur Gegenseite raus kommt.

Ich hab aufm Notebook noch nen Trace von ner Unify, ich schau morgen mal rein wie das da aussieht.

Gesendet von meinem SM-G950F mit Tapatalk
 
Zuletzt bearbeitet:
Hier mal der Screenshot von Wireshark
wireshark.png

Ich hab jetzt nochmal etwas genauer hingesehen. So wies aussieht, hab ich wohl den Verkehr über die LAN1 Verbindung mitgeschnitten. Das ist die Verbindung zum Switch, und demnach die, über die jeglicher Internet-Traffic aus dem Netzwerk läuft. Mal abgesehen von dem, was evtl. über den S0 vorbeigeschleust wird. Die Aufzeichnung da betrifft jedoch keine Rufnummer, die über den S0 der Fritte geleitet wird.

Kurz zur Erklärung. Die 192.168.2.2 ist die TK-Anlage im Allgemeinen. Das war auch schon die fixe IP Adresse der Anlage, bevor wir die VoIP Line-Card in die Anlage rein bekommen haben. Die 192.168.2.9 ist die IP der VoIP Line-Card soweit ich den TK-Dienstleister richtig verstanden habe. Die ist jedoch nicht per extra LAN-Kabel angeschlossen, der Verkehr soll wohl über die einzige LAN Schnittstelle von dem Teil laufen.
Im Netzwerk sehe ich auch die beiden Geräte einzeln an der Fritte, obwohl nur mit einem Kabel angeschlossen. Egal, weiter...

Was mich minimalst stutzig macht, ist dieses KyushuMa. Da stimmt die Mac-Adresse bis auf die letzte Zahl mit der Mac-Adresse der Telefonanlage überein. Die hat eigentlich 84 und nicht 85 am Ende. Ich werde daher wohl die Aussage von oben revidieren müssen, dass es sich da um Hardware der Telekom handelt. Ich denk das wird möglicherweise meine eigene sein.
Die Mac-Adresse der Destination ist unstrittig die der Fritte, die IP 217.0.4.196 sowie 217.0.27.107 gehören allerdings der Telekom. Rein von Source + Destination IPs kommunizieren so wie ich das sehe meine Anlage und die Telekom Server direkt.

Warum der S0 in Betrieb ist und nur ankommende Gespräche von 3 MSN drüber geleitet werden hatte einen speziellen Grund, ich weiß ihn nur offen gestanden nicht mehr genau. Ich meine es hatte irgendwas mit den Lizenzen für die Sprachkanäle des DSP auf der Line-Card zu tun. Da jedoch von den Abbrüchen auch Gespräche über MSN betroffen sind, die definitiv nicht über den S0 zur Anlage geroutet werden, sollte das insgesamt nicht das Problem sein.

Mitschnitt direkt von der Panasonic würde ich machen, wenn ich wüsste wie. Mit Wireshark krieg ich soweit ich es bislang verstehe ja nur einen Mitschnitt der LAN-Schnittstelle des PCs, auf dem Wireshark läuft. Für den gesamten Netzwerkverkehr muss ich mich ja irgendwie dessen bedienen, was die Fritzbox mitschneiden kann. Oder gibts da noch andere Wege? Oder generell - an welchem Punkt muss ich den Mitschnitt ansetzen, damit das was wird?

Wir und die TK-Dienstleister sind so eine unendliche Geschichte. Der Wechsel zum aktuellen hat schon viel Verbesserung gebracht. Ich bin jetzt aber auch bei dem an einem Punkt, wo es schlicht unbezahlbar wird wenn ich die alleine Fehler suchen lasse, und nicht von selbst schon vorgeben kann, wo der Schuh möglicherweise drückt. Derzeit ist der Stand, dass die sagen, die Anlage ist ok. Die Telekom dasselbe.
Allein die Idee die Datenpakete mitzuschneiden ist schonmal ein gutes Stück mehr als die von sich aus getan oder angeboten hätten.

Grüße
Thomas
 
Ich würde Wireshark erst mal nur nach SIP filtern, das macht das noch etwas übersichtlicher, was anderes interessiert und eigentlich sowieso nicht. Einen Trace mit Gespräch hab ich tatsächlich leider keinen da, nur Registrierungen. KyushuMa steht für Panasonic, das ist also auf jeden Fall was von der Anlage, vermutlich die Line Card. Source und Destination für das Goodbye würden passen, das wäre dann von der Anlage. Leider sieht man auf deinem Screenshot aber nicht was davor schon alles passiert ist, da würde der SIP Filter auch helfen.
Wenn es um DSP Lizenzen geht dann macht das ganze halbwegs Sinn, da sollte wohl entweder Geld gespart werden oder die Anlage kann einfach nicht mehr Kanäle.

Zumindest bei Unify ist es so, das du einen TCP Dump direkt in der Anlage aufzeichnen kannst, diesen dann runterladen und mit Wireshark analysieren. Nach so einer Möglichkeit würde ich mich da auch mal umsehen, dann bekommst du das gleich direkt von der Anlage mit.
 
An der Anlage direkt scheint sich nichts mitschneiden zu lassen. Ich hab jetzt mal das Protokoll nach SIP gefiltert. Ganz komisch, 'n Haufen 180 Ringing davor. Das sieht so aus als wär angerufen worden und einfach niemand hätte geantwortet und dann legt unsere Anlage irgendwie auf.
Aber das ist relativer Bullshit, ich saß doch im Büro und just in dieser Minute/Sekunde gabs einen dieser Abbrüche. Sonst hätte ich die Protokolle ja nicht genau an der Stelle untersucht...
Ich muss nochmal länger protokollieren und die Leute mit Abbrüchen bitten die Uhrzeiten aufzuschreiben.

Grüße
Thomas
 
Du meinst von Anlage zu Angerufenem hast du 180 und dann nach Zeit X legt die Anlage auf? Kann durchaus beabsichtigt und richtig sein, wenn die Gegenstelle einfach nicht darauf antwortet. Was mir gerade noch eingefallen ist, teilweise kannst du in einem Softclient die Statuscodes in Echtzeit sehen. Phoner wäre hier so mein bevorzugter Kandidat. Da siehst du dann im Statusfenster auch mit welchem Code das Gespräch beendet wurde (406 o.ä.). Wenn du den Fehler damit nachbilden kannst kommst du vielleicht schneller ans Ziel.
 
Screenshot von den DSL Leitungsdaten kannst gerne haben. Ich seh nix ungewöhnliches, das mir sofort ins Auge stechen müsste.
DSL-Leitungsdaten.jpg

Grüße
Thomas
 
was ich sehe:

die leitung ist nach oben hin offen (DSLAM MAX ist das eingestellte Profil 17k), die leitungskapazität (13k) ist der errechnete Wert der FB (das kommt meistens gut hin), damit verbindet sich die FB auch ca (13k).

das problem was ich sehe, ist dass die leitung am limit läuft, was man am SNR (störabstandsmarge) erkennen kann, 6db ist die untere grenze, alles darunter wird instabil. bzw. die leitung ist jetzt schon instabil.

was man probieren kann:

1. in der fritte direkt im reiter "störsicherheit" den regler etwas nach links schieben (stabiler)

ich seh grad, inzwishcen kann man wohl die SNR direkt anpeilen, hab ich live noch nicht gesehen, wäre auch ne idee den hochzusetzen:

https://service.avm.de/help/de/FRITZ-Box-Fon-WLAN-7490/014/hilfe_internet_dslsnrset

2. Leitung beim Provider runterschrauben lassen, auf 12k-profil z.B., dann verbindet sich die FB weniger schnell, aber womöglich stabiler
 
Die Frage für mich wäre, welche SNR wohl erstrebenswert wäre?
Dass die Leitung am Limit läuft ist mir relativ bewusst. Zwischen mir und der Vermittlungsstelle liegen um die 1600 - 2000m Kupfer ;)

Das sollte sich aber in sehr absehbarer Zeit drastisch reduzieren. Ich hab ein neu aufgestelltes und mit Glasfaser angebundenes MFG in Sichtweite. Die V-DSL Aufschaltung mit Vectoring ist eigentlich auf November angekündigt. Ich erhoffe mir allein davon schon sehr viel.


Störsicherheit erhöhen und Leitungsgeschwindigkeit dadurch drosseln ist schwierig. Wir laufen jetzt schon ziemlich auf Anschlag was die Kapazität betrifft, bzw. es ist jetzt schon wirklich ständig die Leitung dicht wenn irgendwer im Büro auch nur irgendwas macht. Grad muss ich zwangsnotwendig wieder für was ein 2GB Update ziehen und hab damit die anderen für eine schlappe halbe Stunde massiv in der Arbeit beeinträchtigt. Und so kann man das dann Tag für Tag wiederholen. Drossle ich die Leitung noch weiter, potenziert sich das irgendwo gefühlt ins Unendliche. Ein kleiner Teufelskreis.

Direktausbau der Telekom auf Glasfaser hätte sich in den letzten Jahren nicht gelohnt, da wir die 2km wohl vollständig hätten zahlen müssen incl. Hardware und so...

Ich kann zum Test aber mal die Störsicherheit hoch stellen und schauen was passiert. Für einen Tag sollte man das überleben können.

Grüße
Thomas

- - - Updated - - -

Mal an den Reglern zur Störsicherheit gespielt... Mittlere Einstellung hat jetzt einen Sync mit 13k glatt zur Folge. SNR in Empfangsrichtung rauf auf 8, Senderichtung unverändert bei 6. Ob das jetzt so der Stein der Weisen war?
Sofort auch wieder den ersten CRC Fehler auf der Leitung. Mal sehen wie und wo sich das einpendelt.

Grüße
Thomas
 
Hatte oben ja geschrieben, dass QoS bereits voll umfänglich eingerichtet ist^^

Ich schau jetzt mal wie's mit dem neuen Profil läuft.

Grüße
Thomas
 
Tja, was soll ich sagen. Ich kann nur sagen, dass ich noch nichts sagen kann xD

Ich hab ja erst am Freitag den 27.11. umgestellt. Sa + So ist naturgemäß wenig bis nix zu telefonieren im Büro. Montag hatten alle Mitarbeiter Brückentag und frei, Dienstag + Mittwoch waren Feiertage bei uns. Das heißt du fragst mich jetzt nach ca 7-9h im "echten" Livebetrieb :shot:

Bis jetzt keine Beschwerden über Abbrüche. Aber so dann und wann hatten wir auch so abbruchfreie Tage. Das muss noch nix heißen.
CRC Fehlerrate ist im "Grundrauschen" weniger geworden. Ich kann aber über den 24h Verlauf trotzdem deutliche Spikes sehen. Die SES sind im Verhältnis auch nicht weniger geworden. Könnte mir durchaus vorstellen, dass es wieder Probleme gibt, wenn diese Zeiten mit Spike in den CRCs und viel Telefonaufkommen zusammenfallen. Muss ich die kommenden Tage bzw morgen und dann ab Montag wieder weiter beobachten.

Ich werde mich melden, sobald ich genug Stunden unter echten Bedingungen zusammen habe, um nicht nur von einem Zufallstreffer berichten zu können und dann evtl. 3 Tage später zu revidieren :fresse:

Grüße
Thomas
 
So, also... Ich traue mich mal einen vorsichtigen Zwischenbericht abzugeben. Ich hab über die letzten Tage gefühlt weniger Beschwerden über Verbindungsabbrüche gehabt als sonst. Aber die Zeitspanne ist mir immer noch zu kurz, um eine klare Aussage treffen zu können.

Geändert wurde das Profil auf der Fritte, sodass nun 8 dB anstelle 6 dB SNR in Empfangsrichtung bestehen. In Senderichtung ergab sich keine Verbesserung. Nach wie vor auf 6 dB. Durch das etwas weniger aggressive Setting hat sich der Downstream von 13,8k auf 13k verringert, Upstream unverändert auf 1k.

Ich bin wirklich, wirklich gespannt was passiert, wenn in ein paar Wochen die Umschaltung von ADSL 2+ auf VDSL kommt. Die Glasfaser liegt bis zum Verteilerkasten 100 Meter vor der Haustüre. Damit wird meine Kupferstrecke um ca 2km verkürzt. Das sollte deutlich bessere SNRs insgesamt geben. In dem Zuge gibts dann auch VDSL 50k oder direkt 100k. Bitter nötig... Mit der Umstellung werden die Fehler hoffentlich weniger und nicht mehr.

Grüße
Thomas
 
Nachdems jetzt eine Weile gut war, ist wieder alles auf Anfang. Heute vielleicht sogar der schlimmste Tag überhaupt. Die weniger scharfe Profil, das ich in der Fritzbox eingestellt hab scheint irgendwie ausgehebelt. Mit den Reglern mehr Richtung Störsicherheit hatte ich ja eigentlich nur noch 13k Downstream. Nach dem Leitungsreset durch die Telekom hab ich plötzlich trotz gleich hoher SNR mit dem weniger scharfen Profil 13,7k Downstream sync, was laut Anzeige der maximalen Leitungskapazität entspricht. Ganz komisch...

Die Auskunft ist abermals, dass die Leitung vollkommen in Ordnung sei. Überhaupt kein Problem. Da man ja nicht gänzlich ausschließen kann, dass die Leitungen der anderen scheiße sind, fragt man ja rum... Bei den Kunden mit denen auffällig häufig Abbrüche fabriziert werden angefragt: Nein, überhaupt keine Probleme. Man lache intern schon immer etwas, wenn man unsere Nummer im Display sehen würde, und stellt sich schon drauf ein, dass das Gespräch alle 40 Sekunden unterbrochen wird. Tjo.


Hat mir jemand Tipps wie man weiter vorgehen könnte? Der Senior ist hier völlig am Kochen, kann ich auch verstehen - sowas ist bei wichtigen Telefonaten schon geschäftsschädigend solangsam...
So, als nächstes soll jetzt der Telekommunikationstechniker kommen und unsere Anlage von hinten bis vorne durch messen und auf Papier bestätigen, dass die einwandfrei funktioniert. Dann darf die Telekom mit Messtechniker anrücken, gerne auch einer von diesen ominösen hochbezahlten externen Ingenieuren mit 250 Euro Stundensatz. Keine Ahnung obs sowas gibt, aber man muss die alten Leute fertig reden lassen. Und wenn der dann fertig ist und auch keinen Fehler findet, will er wahlweise einen der beiden verklagen. Ei... Ich bezweifle die Erfolgsaussichten, aber gut. Das was ein verlorener Prozess und das ganze Vorgeplänkel kostet könnte er in 100 Meter Gehweg aufreißen und vom MFG in den Keller FTTH legen lassen ausgeben. Dann wär zumindest Signaleinstreuung irgendwo aufm Weg ausgeschlossen und jo... Glasfaser ist Glasfaser.

Ich bin gespannt ob irgendwer irgendwo was findet :fresse:

Grüße
Thomas
 
Mit dem TK-Dienstleister telefoniert... Also, es läge daran, dass die installierte DSP Linecard in der NCP-500 mit der Telekom nicht könne. Alle Provider außer der Telekom würden bei VoIP über UDP kommunizieren, nur die Telekom über das TCP Protokoll. Hierfür sei für unsere Anlage und die verbaute Zusatzkarte keine Freigabe von Panasonic erfolgt und auch nicht möglich.

Aber mal unter Pfarrerstöchtern - müsste in diesem Fall nicht alles oder garnichts funktionieren? Es ist doch nicht so, dass die Anlage per UDP was rausschüttelt und die Telekom das dann ohne Probleme annimmt und nur sporadisch dann sagt... oh, falsches Protokoll, wir trennen dann mal das Gespräch? Weiß irgendwer was zu der Protokollgeschichte bei Telekom VoIP?

/edit: Also, ich konnte heute mal noch einen dieser Verbindungsabbrüche mitschneiden. Beim Abbruch ist folgendes Bild sichtbar:

In der Paketübersicht als Source die Gegenseite, Destination die TK Anlage, Status 500 Timeout sending SIP message. Wenn ich dann reinschaue sehe ich folgendes:
SIP-Abbruch.jpg

Das wiederum sieht so aus, als würde das von uns an die Gegenseite gesendet? Kann da wer Licht ins Dunkel bringen? Davon ab sieht es so aus, als ob das doch alles "sauber" über UDP läuft? Insofern die Telekom ihre VoIP Geschichten ausschließlich über TCP abwickeln würden, dürfte eine Übermittlung via UDP doch nicht im Ansatz laufen. Da dürfte kein einziges Telefonat rein oder raus gehen. Wir sprechen hier ja aber nur von sporadischen Abbrüchen...

Grüße
Thomas

/edit2: 18:05 - Man soll dem Teufel ja immer nicht nur auf den Schwanz, sondern auch auf beide Eier treten. Man nehme: Ein 15 Jahre altes schnödes Analogtelefon, ballere das an den FON1 des Routers, nehme eine freie nicht in der Anlage verwendete MSN, konfiguriere die auf den Apparat und telefoniere damit wild durch die Gegend. So richtig wild. All die schönen Nummern wählen, die den Tag über hinweg konstant von Abbrüchen gezeichnet waren. Wahllos, wild. Als ob es kein Morgen mehr gäbe. Entweder ist die Uhrzeit schuld, dass es gerade so richtig lüppt, oder der 15 Jahre alte Knochen in Verbindung mit der Fritte und VoIP funktioniert besser als die tausende Euro teure TK-Anlage. Morgen wird das Teil wie die Meisterschafts-Schale herumgereicht und jeder der Probleme hat, wird das Gespräch über den alten Knochen nochmal führen.
Ergebnisse werden folgen.
 
Zuletzt bearbeitet:
Hallo!
Ich habe eine Frage bzw. Bitte ... ich habe ein KX-NCP500XNE erhalten. Ich habe mir jetzt eine 4er DSP besorgt - jedoch leider ist die SD-Karte formatiert. Sprich, da geht gerade gar nix....
Hat hierzu Bitte jemand die firmware?

Danke vielmals im voraus!
LG
Jürgen
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh