VCM/Fax: T.38-Aushandlung und T.38-Übertragung schlagen fehl

Forum zu LANCOM Systems VoIP Router/Gateways und zur LANCOM VoIP Option

Moderator: Lancom-Systems Moderatoren

Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: VCM: T.38-Aushandlung schlägt fehl wegen falscher Call-S

Beitrag von Jirka »

Ja, Mist. Du hast Recht, das ist es nicht. Das machen viele Geräte (gerade ein paar Telefone durchgespielt), aber es ist nicht vorgeschrieben.
In dem Buch "SIP: Understanding the Session Initiation Protocol, Fourth Edition" steht:
Each user agent maintains its own command sequenze number space. For example, consider the case where UA 1 establishes a session to UA 2 and initializes its CSeq count to 1. When user agent 2 initiates a request (such as INVITE or INFO, er even BYE) it will initialize its own CSeq space, totally independet of the CSeq count used by UA 1.
(Quelle: https://books.google.de/books?id=GkOPCw ... ip&f=false)

Und nu?, oh nee...
cpuprofi
Beiträge: 1330
Registriert: 12 Jun 2009, 12:44
Wohnort: Bremen

Re: VCM: T.38-Aushandlung schlägt fehl wegen falscher Call-S

Beitrag von cpuprofi »

Hallo Georg,
MoinMoin hat geschrieben:Das LANCOM kann nur Version 0. Da hilft auch eine Konfigurationsmöglichkeit nicht weiter.
na dann mal schnell "T.38 Version 1" in VCM implementieren... Lancom ist doch ein Technologie-Vorreiter... :wink:

Grüße
Cpuprofi
awi
Beiträge: 61
Registriert: 19 Jun 2013, 15:22

Re: VCM: T.38-Aushandlung schlägt fehl wegen falscher Call-S

Beitrag von awi »

Hi zusammen,

um hier einmal Klarheit zu schaffen zum Thema Sequenznummern, habe ich hier einmal Auszüge aus RFC 3261 zusammengetragen, die den Sachverhalt beschreiben:

"12.1 Creation of a Dialog
...
12.1.1 UAS behavior
... The remote sequence number MUST be set to the value of the sequence
number in the CSeq header field of the request. The local sequence
number MUST be empty.

...
12.1.2 UAC Beahvior
... The local sequence number MUST be set to the value of the sequence
number in the CSeq header field of the request. The remote sequence
number MUST be empty (it is established when the remote UA sends a
request within the dialog).
...
12.2 Requests within a Dialog
... Once a dialog has been established between two UAs, either of them
MAY initiate new transactions as needed within the dialog. The UA
sending the request will take the UAC role for the transaction. The
UA receiving the request will take the UAS role. Note that these may
be different roles than the UAs held during the transaction that
established the dialog.
...
12.2.1 UAC Behavior
12.2.1.1 Generating the Request
... Requests within a dialog MUST contain strictly monotonically
increasing and contiguous CSeq sequence numbers (increasing-by-one)
in each direction (excepting ACK and CANCEL of course, whose numbers
equal the requests being acknowledged or cancelled). Therefore, if
the local sequence number is not empty, the value of the local
sequence number MUST be incremented by one
, and this value MUST be
placed into the CSeq header field. If the local sequence number is
empty, an initial value MUST be chosen
using the guidelines of
Section 8.1.1.5. The method field in the CSeq header field value
MUST match the method of the request.
..."

Also zusammengefasst:
Der Empfänger des ersten INVITE setzt seine Remote Sequenznummer auf den Wert aus dem INVITE (und verwendet diesen in Responses).
Seine lokale Sequenznummer bleibt leer.
Nachdem der Dialog nun aufgebaut wurde, kann ein erneuter Request gesendet werden.
Wenn dies der Sender des ersten INVITE macht, dann inkrementiert er seine lokale Sequenznummer um 1.
Macht dies der Empfänger inkrementiert er ebenfalls seine lokale Sequenznummer um 1, sofern es bereits eine gibt.
In diesem Fall ist diese aber noch nicht vorhanden. Also vergibt er einen initialen Wert und verwendet diesen im Request.

Ich hoffe,ich habe hier für etwas Klarheit gesorgt.

Viele Grüße
awi
awi
Beiträge: 61
Registriert: 19 Jun 2013, 15:22

Re: VCM: T.38-Aushandlung schlägt fehl wegen falscher Call-S

Beitrag von awi »

Oh da gab es wohl ein paar Überschneidungen in unseren Beiträgen. :D
Benutzeravatar
MoinMoin
Moderator
Moderator
Beiträge: 1978
Registriert: 12 Nov 2004, 16:04

Re: VCM: T.38-Aushandlung schlägt fehl wegen falscher Call-S

Beitrag von MoinMoin »

Moin Cpuprofi!
cpuprofi hat geschrieben:
MoinMoin hat geschrieben:Das LANCOM kann nur Version 0. Da hilft auch eine Konfigurationsmöglichkeit nicht weiter.
na dann mal schnell "T.38 Version 1" in VCM implementieren... Lancom ist doch ein Technologie-Vorreiter... :wink:
Sollte nicht notwendig sein, da, soweit ich mich erinnere, der Support von Version 0 für T.38 immer gewährleistet sein muß.

Ciao, Georg
Koppelfeld
Beiträge: 967
Registriert: 20 Nov 2013, 09:17

Re: VCM: T.38-Aushandlung schlägt fehl wegen falscher Call-S

Beitrag von Koppelfeld »

Jetzt habe ich mir richtig Mühe gegeben mit einer Antwort, und stattdessen wurde der Beitrag gespeichert, auf den ich Bezug nahm. Gelöscht.
Benutzeravatar
MoinMoin
Moderator
Moderator
Beiträge: 1978
Registriert: 12 Nov 2004, 16:04

Re: VCM: T.38-Aushandlung schlägt fehl wegen falscher Call-S

Beitrag von MoinMoin »

Moin, moin!

Also ist nicht nur strenge Monotonie gefordert, sondern auch eine Erhöhung um exakt 1. In obigem Beispiel macht die Fritz-Box das übrigens auch nicht anders. Sie wählt halt als initiale Sequenznummer die 2 und zählt dann brav jeweils um 1 hoch.

Ciao, Georg
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: VCM: T.38-Aushandlung schlägt fehl wegen falscher Call-S

Beitrag von Jirka »

Hallo zusammen,
awi hat geschrieben:Also zusammengefasst:
Der Empfänger des ersten INVITE setzt seine Remote Sequenznummer auf den Wert aus dem INVITE (und verwendet diesen in Responses).
Seine lokale Sequenznummer bleibt leer.
Nachdem der Dialog nun aufgebaut wurde, kann ein erneuter Request gesendet werden.
Wenn dies der Sender des ersten INVITE macht, dann inkrementiert er seine lokale Sequenznummer um 1.
Macht dies der Empfänger inkrementiert er ebenfalls seine lokale Sequenznummer um 1, sofern es bereits eine gibt.
In diesem Fall ist diese aber noch nicht vorhanden. Also vergibt er einen initialen Wert und verwendet diesen im Request.

Ich hoffe,ich habe hier für etwas Klarheit gesorgt.
ja, hast Du. Ganz große Klasse. Danke.
Blöd ist nur, dass ich das nicht wusste und jetzt das Rätselraten losgeht, was der Gegenseite denn nun nicht gefällt! Und ob das, was der Gegenseite nicht gefällt, auch wirklich falsch ist.

Ich sitze hier jetzt also und vergleiche ein Paket mit dem anderen. Natürlich gibt es Unterschiede. Ich versuche diese jetzt rauszuarbeiten.

Ein Punkt ist z. B., dass der LANCOM bei dem T.38-(Re-)INVITE zum Provider die Authorization:-Zeile mit angibt. Die FRITZ!Box macht das nicht und kommt auch so durch.
Koppelfeld hat geschrieben:Jetzt habe ich mir richtig Mühe gegeben mit einer Antwort, und stattdessen wurde der Beitrag gespeichert, auf den ich Bezug nahm.
Das tut mir jetzt leid, nun müssen wir uns unseren Teil denken.
Mal ein Tipp dazu, es ist ja nicht so, dass mir das nicht auch schon öfter mal passiert ist: Wenn Du einen guten Browser verwendest, gehst Du einfach noch mal eine Seite zurück und hast da dann wieder Deinen geschriebenen Text. Das Ganze passiert, wenn man zwischenzeitlich automatisch ausgeloggt wurde, dann kommt beim Abschicken des Beitrags ein Fehler und Du landest da, wo Du ursprünglich angefangen hattest, nämlich mit dem zitierten Beitrag und das von Dir geschriebene ist weg. Jetzt wie gesagt ganz ruhig bleiben und zurück gehen und nochmals abschicken, das geht dann. Beim IP-Phone-Forum ist die Forensoftware diesbezüglich wesentlich besser, sie speichert sogar Beiträge von Dir ab, die noch nicht fertig sind und Du kannst sie später weiter schreiben. Na ja, so ein Komfort ist hier nicht. Wenn man bei der Anmeldung den Haken für immer angemeldet setzt, passiert das übrigens nicht.
Nun gut, vermutlich habe ich Dir mit den Erklärungen zu den T.38-Problemen so manchen Aha-Effekt erzeugt und Du wolltest nun schreiben, dass Du zukünftig auch auf T.38 setzt :-)

So, nun werde ich mal weiter schauen...

Vielen Dank und viele Grüße,
Jirka
Benutzeravatar
MoinMoin
Moderator
Moderator
Beiträge: 1978
Registriert: 12 Nov 2004, 16:04

Re: VCM: T.38-Aushandlung schlägt fehl wegen falscher Call-S

Beitrag von MoinMoin »

Moin Jirka!

Kannst du im LANCOM mal das T.38 ausmachen und tracen, was dann passiert? Ich würde erwarten, daß auf Providerseite das ReInvite wieder abgelehnt wird, dann aber das von da kommende zu einer T.38-Verbindung führt. Ich tippe auf die Version 1 oder das doppelte a=T38FaxUdpEC.

Ciao, Georg
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: VCM: T.38-Aushandlung schlägt fehl wegen falscher Call-S

Beitrag von Jirka »

Jirka hat geschrieben:Ein Punkt ist z. B., dass der LANCOM bei dem T.38-(Re-)INVITE zum Provider die Authorization:-Zeile mit angibt. Die FRITZ!Box macht das nicht und kommt auch so durch.
Also daran liegt es schon mal nicht. Hatte dafür LCOS 9.24.0252 installiert, wo es dieses (unaufgeforderte) Authorization noch nicht erfolgt. Gleicher Fehler.

@Georg: ja, mach ich.
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: VCM: T.38-Aushandlung schlägt fehl wegen falscher Call-S

Beitrag von Jirka »

MoinMoin hat geschrieben:Kannst du im LANCOM mal das T.38 ausmachen und tracen, was dann passiert? Ich würde erwarten, daß auf Providerseite das ReInvite wieder abgelehnt wird, dann aber das von da kommende zu einer T.38-Verbindung führt.
Es passiert folgendes: Provider lehnt mit "488 Not Acceptable Here" ab wie gehabt. Jetzt der Unterschied, das LANCOM gibt das an die FRITZ!Box so weiter. Also auch hier ein "488 Not Acceptable Here". Das lässt sich die FRITZ!Box nicht gefallen und startet gleich noch mal ein Re-INVITE. Das ist noch nicht mit Authentifizierung angekommen, da kommt der Provider/das Amt mit dem Re-INVITE, was der LANCOM gleich zur FRITZ!Box durchstellt. Die hat daraufhin ihr eigenes Re-INVITE vermutlich vergessen und bestätigt das Re-INVITE vom LANCOM mit OK. Das LANCOM bestätigt beim Provider mit OK. Die ACKs kommen noch. Sieht alles ok aus! NUR: Es geht nicht eine Zeile vom Fax rüber, das Ding steht still. Die FRITZ!Box gibt irgendwann auf und sendet ein BYE.
MoinMoin hat geschrieben:Ich tippe auf die Version 1 oder das doppelte a=T38FaxUdpEC.
Ist sicherlich eine gute Vermutung, aber ich nehme es nicht an, weil der Trace diese Sachen auch enthält, wenn die FRITZ!Box sich selber beim Provider anmeldet und dann beschwert sich der Provider nicht und alles klappt.

Es ist zum Verzweifeln. Manch einer würde jetzt das Handtuch werfen. Aber ich mache nur eine größere Pause...

Vielen Dank und viele Grüße,
Jirka
Koppelfeld
Beiträge: 967
Registriert: 20 Nov 2013, 09:17

Re: VCM: T.38-Aushandlung schlägt fehl wegen falscher Call-S

Beitrag von Koppelfeld »

Hallo Jirka,
Jirka hat geschrieben:
Koppelfeld hat geschrieben:T.38 ist nicht nur BAD (broken as designed), es läuft seit Jahren, wenn überhaupt, extrem unzuverlässig.
nein Koppelfeld, da hast Du keine Ahnung. T.38 selber ist nicht unzuverlässig oder "BAD". Was nichts taugt ist die schlechte Implementierung in vielen Geräten.
Ein Protokoll ist BAD, wenn es so kompliziert ist wie ein EU-Formular.
Manche Menschen sind gefangen in ihrer Dummheit wie das Insekt im Bernstein, den Klassiker von Hilbert hatte ich hier glaube ich schon zitiert, "Es gibt Menschen, die haben einen geistigen Horizont mit dem Radius Null und nennen ihn ihren Standpunkt". Bei Dir ist es weitaus schlimmer: Du verfügst über ein verblüffend hohes Abstaktions- und Deduktionsniveau, gehst aber davon aus, daß jedermann mithalten kann. Trotz extremer Intelligenz, scharfem Verstand und umfassenden Grundlagenwissens fehlt Dir die Weisheit eines William von Ockham: "Entia non sunt multiplicanda sine necessitas", oder, wie die Scholastiker später verschäften, "praeter necessitate".
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.
T.38 war schon immer scheiße, weil irgendeine Komponente *immer* versagte. Oder es lief, aber plötzlich konnte ein Kunde keine Faxe mehr an die Heller-Bank in Friedrichsdorf schicken. Auflösung: QSC als Provider kaufte zeitweise u.a. "Leistungen" bei der Telefónica ein, und die hatten ein kleines Problem mit der Britisch Telecom, die aber der weltweite Carrier für die General Electric Bank war, zu der Heller gehört. Dummerweise aber muß die Kreditsachbearbeiterin tagtäglich viele Faxe genau dorthin schicken. Und es dürfen nur Faxe sein. 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.
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 ?
Denn: Der Dejitterbuffer sorgt wie ein Puffersilo dafür, daß der D/A-Wandler schön gleichmäßig mit einem sauber sortierten Bitstrom versorgt wird. Guck' Dir das Prinzip vom CD-Spieler an: Auch dort wird ein Schwung Sektoren eingelesen und gepuffert. Fällt der Vorrat unter eine bestimmte Marke, beispielsweise dadurch, daß auf eine weiter innen liegende Spur gewechselt wird, wird die Winkelgeschwindigkeit der CD erhöht. "Jitter" findet NICHT statt, außer in der verquasten Gehirnen von selbsternannten HiFi-Gurus wie Joachim Pfeiffer und Reinhard Wendemuth, einer peinlicher als der andere.
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 (und ja, wir haben auch schon 33.600 bps über RTP gejagt) 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.
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.
Zuguterletzt T.38 komplett deaktivieren.


Die Benutzung einer "Fritzbox" stellt ein gemeines Verbrechen dar.

Nimm' einen LANCOM mit eingebautem Analogadapter und vergiß' alle Deine Probleme.

Da wäre einerseits das Problem, dass die Aushandlung von T.38 fehlschlägt, weil irgendwas nicht stimmt - den Fall sehen wir aktuell hier gerade. Es ist unglaublich, wie das immer und immer wieder zu einem Problem wird. Ich hatte schon vor 9 Jahren ähnliche Probleme.
Und Du fährtst immer wieder gegen die Wand ? Bist Du ein Crashtestdummy ?
Man muss hier sagen, dass T.38 aber auch der Sündenbock ist, der da herhalten muss. Ich habe die gleichen Probleme auch ohne T.38 bei einem Re-INVITE.
Das ist gerade mein Problem: Der LANCOM macht einen Reinvite, obwohl er nicht darf.

Auch hier muß man sagen, LANCOM baut zu viele Features ein (Telekom 1TR112, Telekom-VLAN-Negotiation, Manager-Cloud etc., aber die einfachen Dinge funktionieren dann nicht mehr.
Dr.Einstein
Beiträge: 2893
Registriert: 12 Jan 2010, 14:10

Re: VCM: T.38-Aushandlung schlägt fehl wegen falscher Call-S

Beitrag von Dr.Einstein »

Koppelfeld hat geschrieben: Zuguterletzt T.38 komplett deaktivieren.
Ich muss Koppelfeld hier Recht geben. 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. Wenn man Glück hat, gehört das Ziel auch irgendwie zur Firma, sodass man evtl. am Zielfax und/oder Zielkonverter (falls schon weg von POTS/ISDN) etwas einstellen kann. Zu 99% bekommt man aber die Antwort, "alle Anderen können mir Faxe schicken, nur Sie nicht".

Und der Kommentar bezieht sich nicht nur auf Lancom. Es spielt überhaupt keine Rolle, welcher ATA von welchem Hersteller in welcher Kombi. Das einzige Szenario, wo ich T.38 einsetze sind Lösungen innerhalb eines Herstellers, z.B. virtuelle TK Anlage auf einem Server zu einem vom TK Anlagenhersteller unterstützten ATA Adapter. Sollten bei dieser Punkt zu Punkt Verbindung irgendwelche T.38 Probleme auftreten, bekommt halt der Hersteller Tonnen an Supportcases, soll der sich mit seinen Implementierungsschwierigkeiten rumärgern. Außerhalb der Firma sehe ich aber schwarz, da man weder auf die Implementierung des eigenen Providers, des Zielproviders, der Transitprovider und auf das Zielequipment hat. Kurz: Fax über IP ist und bleibt Mist.

Gruß Dr.Einstein
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: VCM: T.38-Aushandlung schlägt fehl wegen falscher Call-S

Beitrag von Jirka »

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.
:roll:
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
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: VCM: T.38-Aushandlung schlägt fehl, Ursache bisher unbek

Beitrag von Jirka »

Hallo zusammen,

so, hier der Stand der Dinge:

FRITZ!Box alleine:

Dass es mit der FRITZ!Box alleine, mit der FRITZ!Box hinter einer FRITZ!Box und mit der FRITZ!Box hinterm LANCOM (direkte Registrierung beim Provider/kein VCM, kein SIP-ALG) funktioniert, hatte ich schon geschrieben. Demnach hat der Provider auch kein Problem mit
a=T38FaxVersion:1\r\n
a=T38FaxUdpEC:t38UDPRedundancy\r\n
a=T38FaxUdpEC:t38UDPFEC\r\n
Es kommt kein "488 Not Acceptable Here" vom Provider. Alles geht sauber durch.

Jetzt mit LANCOM-VCM dazwischen:

Die im letzten Posting aufgeführten Betas aus dem März habe ich wohl mal vor 2 Wochen gelöscht, ich hatte jetzt nur noch die 9.24.0153-RU3 und die 9.24.0212-RU4 in meinem Firmware-Archiv und habe die zum Testen genommen.

Mit der 9.24.0212-RU4 ergibt sich keine Änderung, das Verhalten entspricht der 9.24.0334-SU9. Es geht, solange man die FRITZ!Box auf T.38 lässt, kein Fax durch. Egal ob mit T.38 im LANCOM an oder nicht, es geht nichts rüber.
Anders mit der 9.24.0153-RU3. Hier kommt zwar NACH WIE VOR das "488 Not Acceptable Here" vom Provider. Aber das anschließende Re-INVITE vom Provider geht durch und das Fax kann ohne Probleme empfangen werden.
Warum es mit der RU3 geht und mit der RU4 nicht, ist mir leider noch unklar.

Viele Grüße,
Jirka

Noch eine Ergänzung: Wenn man das mit meinem letzten Faxeingang und dem obigen Bootlog vom LANCOM abgleicht, dann muss das Problem, dass auch das Re-INVITE vom Provider fehlschlägt, zwischen der 9.24.0191 vom 01.02.2017 und der 9.24.0212-RU4 vom 06.03.2017 reingekommen sein. Das erste Re-INVITE geht mit beiden Firmwares nicht. Der Zustand war mit der älteren Firmware also schon schlecht, hat sich aber mit der RU4 noch verschlechtert, so dass seitdem gar nichts mehr geht.
Antworten