Hallo Koppelfeld, hallo Dr. Einstein, hallo zusammen,
vielen Dank für Eure Anteilnahme, Eure Mühe und Euren Rat. Ich weiß das sehr zu schätzen.
Während Ihr hier die Beiträge geschrieben habt, lag ich mit rechteckigen Augen im Bett und grübelte, was denn die Ursache dieses Problems ist. Ich meine eins steht doch fest: Unabhängig von dem, was Ihr jetzt sagt, gibt es hier doch ein Problem. Ein Problem was gefixt werden sollte. Denn irgendwas macht der LANCOM-VCM falsch. Und das will ich jetzt geklärt haben. Wie ich das anstelle, weiß ich auch nicht, es geht natürlich nur, wenn Georg mitmacht, weil alleine komme ich hier definitiv nicht weiter.
Was mir heute nacht einfiel war, was ist denn eigentlich mit Deiner eigenen FRITZ!Box?
(Für Koppelfeld zur Info: Ich kann die nicht aus dem Fenster schmeißen, weil die von meinem Provider ist und wenn der auf die Idee kommt, die SIP-Kennwörter zu ändern, muss ich die FRITZ!Box anschließen, um diese per TR-069 zu bekommen. Da kann ich sie dann auslesen und in den LANCOM eintragen.) Die macht doch Fax-to-E-Mail. Ich habe lange mehr kein Werbefax mehr bekommen fiel mir daraufhin auf. Ich beschloss im Bett zu bleiben und schlafen zu wollen und morgen früh mir selber mal ein Fax zu schicken. Ja, was soll ich sagen? Das gleiche Problem! Ich kriege deswegen keine Werbefaxe mehr, weil ich gar keine Faxe mehr kriege. Ich habe das nur nicht mitbekommen, weil wer schickt mir schon ein Fax, obwohl, neulich gab es jemanden, der auf einem Angebot die Faxnummer vermisste. Das Blöde ist, dass ich hier auch eine Faxnummer eines wichtigen Kunden über diese FRITZ!Box abwickle und ihm das per E-Mail zustelle, weil ich bei ihm die FRITZ!Box tatsächlich entsorgt habe. Das heißt, der hat auch keine Faxe mehr bekommen. Und niemand merkt es, dass die Aufträge ausbleiben. Das ist schon bitter. In einem Systemhaus hat jemand damals für PRTG einen Sensor erstellt, der jede Nacht dem Kunden ein Fax schickte und überprüfte, ob dies auch ordnungsgemäß angekommen ist. Ich fand das übertrieben, heute weiß ich, dass man tatsächlich alles prüfen muss - im Prinzip auch die Nichterreichbarkeit von Management-Funktionen übers WAN-Interface - wenn man sichergehen will, dass wirklich alles läuft. Das heißt jetzt im Umkehrschluss aber, dass es irgendwann noch mit dem LANCOM funktioniert hat. Mein letztes Fax habe ich am 06.03.17 empfangen, so steht es im E-Mail-Programm. Wenn allerdings danach noch ein Werbefax eingetrudelt ist, wovon ich ausgehe, dann kann das auch gelöscht worden sein.
Ok, wir haben ja alles da. Das schaue ich mir im Laufe des Tages mal an. Eingekürztes Bootlog meines LANCOMs:
Code: Alles auswählen
02/02/2017 18:20:03 System boot after firmware upload VERSION: 9.24.0191 / 01.02.2017
03/11/2017 03:55:41 System boot after firmware upload VERSION: 9.24.0213 / 08.03.2017
04/05/2017 15:12:33 System boot after firmware upload VERSION: 9.24.0217 / 15.03.2017
04/08/2017 03:55:48 System boot after firmware upload VERSION: 9.24.0231 / 06.04.2017
05/06/2017 03:55:37 System boot after firmware upload VERSION: 9.24.0244 / 02.05.2017
Ansonsten habe ich gestern Abend natürlich noch mal geschaut, Pakete verglichen, nach Angaben im SIP/SDP gegoogelt usw. Meiner Meinung nach ist in absteigender Wahrscheinlichkeit irgendwas mit folgenden Angaben faul:
1) m=image 15070 udptl t38 101
Hier stört mich die 101 am Ende.
2) a=ptime:20
Kann/muss man einem T.38-Protokoll den Zeitumfang von 20 ms vorschreiben? Die Pakete kommen alle 20 ms, ja, aber sie enthalten ja nun nicht 20 ms Sprachdaten.
3) a=rtpmap:101 telephone-event/8000\r\n
4) a=fmtp:101 0-15\r\n
Beides zusammen: ja sollen jetzt DTMF-Töne oder Faxe übermittelt werden? Ist das überhaupt vereinbar?
Koppelfeld hat geschrieben:Ich sehe mich dem Kunden gegenüber verantwortlich und will ihm damit eine einfache, zuverlässige Umgebung an die Hand geben. Dabei ist mir dieses "praeter necessitate" sehr wichtig. NIEMALS komplizierter als unbedingt nötig.
Wie wahr!!! Prinzipiell will ich ja das Gleiche. Es soll sauber und ordentlich funktionieren. In der Vergangenheit hatte ich mit T.38 gute Erfahrungen gemacht. Vielleicht ist das mittlerweile nicht mehr wahr. Und ich gehe immer noch von dieser Tatsache aus. Wenn ich lese, was Dr. Einstein geschrieben hat, dann könnte man das wie folgt erklären: Vielleicht hat es bei mir immer so toll funktioniert mit dem T.38, weil die Gegenseite in der Vergangenheit (immer/meist) der Provider war (1&1 z. B.). Und mit dem funktioniert T.38 reibungslos. Wenn nun andere SIP-Clients direkt mit T.38 kommen und nicht mehr der Provider, dann kann es hier vielleicht eher krachen, als in der Vergangenheit (wegen Inkompatibilitäten). Bisher habe ich aber keine Beschwerden bekommen.
Koppelfeld hat geschrieben:T.38 war schon immer scheiße, weil irgendeine Komponente *immer* versagte.
Ja, aber nicht weil die Komponente versagte, sondern weil die Komponente einen Bug hatte.
Natürlich ist T.38 jetzt in gewisser Weise anspruchsvoll, es muss erst mal im laufenden Gespräch ausgehandelt werden. Das könnte man jetzt auch als Designschwäche bezeichnen. Aber es kann doch auch nicht sein, dass da außer solchen Leuten wie Dr. Einstein niemand den Firmen auf die Füße tritt und sagt, was macht ihr hier.
Schau es Dir doch an, wie es im Alltag läuft: Hans, also der, der sich hier in diesem Thread mit dem gleichen Problem gemeldet hat, ist doch das beste Beispiel. Da wird ein Workaround gefunden und dann bleibt es dabei. Wobei ich Hans jetzt KEINEN Vorwurf mache! Würde er der Sache im Detail nachgehen, tracen, untersuchen, Hersteller/Provider kontaktieren usw. usf. dann würde er sich aufgrund des Zeitaufwandes in den Ruin wirtschaften. Ich sehe es ja selber: Was ich hier mache ist wirtschaftlich nicht vertretbar. Daraus folgt: Bugs, wo es einen leichten Workaround gibt, bleiben uns erhalten. Und wenn es kompliziert ist, also mehrere Herstelle/Provider im Spiel sind, gibt es niemanden, der sich der Sache annimmt und klärt, wen hier die Schuld trifft.
Koppelfeld hat geschrieben:Frage die 'mal nach T.38, aber aufpassen: Sie spielt nebenbei Handball, ist in der Ortsfeuerwehr aktiv, hat keinerlei Skrupel, dafür aber einen umso fürcherlicheren Schlag.
Koppelfeld hat geschrieben:Und warum diese kranke Ausgeburt eines praxis- und nutzenfernen Hirnwichsers implementieren, wo es doch die ganz normale Übertragung mit g.711a auch tut ? Und zwar störungsfrei ?
Die Erfahrung habe ich eben nicht gemacht. Es geht mittlerweile gut, das habe ich auch geschrieben. Aber nicht störungsfrei. Ich habe hier in diesem Forum mit Georg mehrmals Faxprobleme diskutiert im März/April - es war nicht in den Griff zu bekommen. Wie schon geschrieben, der Kunde hat 350 Faxe am Tag. Per E-Mail scheidet aus, ist nicht zulässig bzw. die Gegenseiten haben noch nicht dieses zertifizierte E-Mail-Dings. Wenn er die Faxe per Post sendet kostet das 350 EUR am Tag zzgl. Arbeitslohn. Der Kunde hätte also kein Problem damit, LANCOM mal eben 5.000 EUR zu überweisen, damit die Sache funktioniert. Mittlerweile ist der LANCOM da rausgeflogen, also nicht ganz, steht noch im Schrank. Aber die Faxe macht jetzt irgendso eine teure Box (mit fällt gerade der Name nicht ein, aber "Box" kam glaube ich in der Bezeichnung vor). Ich habe ihm gesagt, die kochen auch nur mit Wasser. Wie der Stand der Dinge derzeit ist, weiß ich nicht genau, ich habe nicht die Zeit, mich um alles zu kümmern.
Im Januar darf ich ein Faxgerät über WLAN anbinden. Da graut mir jetzt schon vor. Da wollte ich, um das mit dem unkalkulierbare WLAN in den Griff zu bekommen, auch auf T.38 setzen. Mit G.711 würde ich mir das da nicht trauen.
Wenn ein normaler Kunde ankommen würde, würde ich das natürlich ablehnen. Der Kunde kennt mich aber persönlich und daher kann ich da nicht einfach nein sagen.
Koppelfeld hat geschrieben:Beim Faxen, und das hatte ich in mühevoller Kleinarbeit ausgearbeitet, bevor die Forumssoftware alles zerstörte, sind noch zwei Dinge wichtig: Zum einen darf der Dejitterbuffer nicht zu groß werden, sonst wird die effektive Roundtripzeit zwischen Sender und Empfänger so groß, daß der im Faxgerät befindliche "Line Echo Canceller" aus dem Tritt kommt. Zum Anderen kann man nicht über die Geschwindigkeit bestimmen, mit der die Daten einlaufen. Ein 'buffer underrun' erzeugt einen Fehler, aber den erkennt ECM und die Zeile wird wiederholt. Ein 'buffer overrun' ist subtiler, hier versucht nämlich der ATA, "die Daten beschleunigt 'rauszupusten". Bei Telephonaten stört das nicht, aber beim Faxen oder gar bei V.34 - Übertragung [...] variiert die Trägerfrequenz, was man mit einem (Analog-) Oszillographen sehr schön sehen kann. Ein "Jaulen" des Trägers aber, und sei es noch so gering, bringt im Faxgerät die Quadraturamplitudendemodulation durcheinander.
Koppelfeld, ich bin immer wieder beeindruckt. Wenn ich nicht schon öfter einen "Ossi" in der Hand gehabt hätte, würde ich auch gar nichts verstehen...
Koppelfeld hat geschrieben:Daher - und LANCOM war so klug, diese Einstellungen zu bieten - stellst Du im ATA den Dejitterbuffer von 'adaptive' auf 'fixed' und die Größe auf 'small'. Und natürlich kann man beim LANCOM auch noch die Echokompensation ausschalten, denn: Zwei Kompensatoren können übel interferieren.
Letzteres ergibt aber bei einem SIP-Client keinen Sinn bzw. keine Wirkung - wenn der LANCOM nur SIP-Proxy ist, dann ist der Echo-Canceler ohne Funktion. In diesem Fall befinde ich mich jetzt gerade.
Koppelfeld hat geschrieben:Nimm' einen LANCOM mit eingebautem Analogadapter und vergiß' alle Deine Probleme.
Da DSL-Anschluss und Faxgerät nicht beide an der gleichen Stelle stehen und die Kabelverbindung dazwischen entweder nur für Ethernet oder Telefonie genutzt werden kann, hatte ich es erst mal mit einem 1781VA versucht ohne analoge Schnittstelle. Und nur wegen des Faxes stelle ich da jetzt nicht auch noch einen 1783VA(W) hin.
Koppelfeld hat geschrieben:Das ist gerade mein Problem: Der LANCOM macht einen Reinvite, obwohl er nicht darf.
Das habe ich aber auch noch nicht verstanden das Problem. Du kannst in WEBconfig ganz einfach einen Wireshark-Trace machen: Extras -> Paket-Capturing (Was für ein Deutsch-Englisch-Gemisch übrigens, ich hätte es als Packet-Capturing bezeichnet.) bzw. https://<IP-Adresse_oder_Name>/pcap/
Dr.Einstein hat geschrieben:Auf den ersten Blick dachte ich, T.38 löst gewisse Architekturlücken bei SIP bzw. G.711, aber was ich in den letzten Monaten für massive Probleme mit diesem sch*** Protokoll hatte, passt auf keinen Zettel. Es gibt immer wieder irgendeine Zielrufnummer, die will einfach nicht mit T.38.
Ja, z. B. derzeit meine Faxnummer, die von einem Kunden und die, wo ich hier jetzt aktuell dran rumfummel. Die Apotheke von Hans und vermutlich noch tausend andere. Da kannst Du egal mit welchem Gerät kommen, T.38 tut es nicht. Aber wenn es funktionieren würde, dann bin ich immer noch der Auffassung ist es eine gute Sache. Alleine schon wenn Ihr das Ganze mal in Wireshark betrachtet. Was man da mit T.38 alles sieht, das war mir so gar nicht bekannt.
Natürlich betrifft das auch andere Hersteller. Im Prinzip ist es aber mit SIP doch das Gleiche. Der Standard ist eine Katastrophe und trotzdem wird er genutzt.
Dr.Einstein hat geschrieben:Und der Kommentar bezieht sich nicht nur auf Lancom. Es spielt überhaupt keine Rolle, welcher ATA von welchem Hersteller in welcher Kombi.
Ja, hier schreibst Du es ja. Aber das ist doch schlimm.
Dr.Einstein hat geschrieben:Kurz: Fax über IP ist und bleibt Mist.
Ich habe das noch mal fett formatiert. Ich finde das trifft die Sache auf den Punkt. Und ist ein schöner Schlusssatz sowohl von Deinem Posting, als auch von meinem Posting hier.
Vielen Dank und viele Grüße,
Jirka