Hylafax-Schluckauf – was ist hier los?

Hylafax-Schluckauf – was ist hier los?

Wir betreiben einen Hylafax-Server (6.0.6-7+deb9u1), der auf einem Raspberry Pi (3) installiert ist und Raspbian Stretch ausführt. Die daraus resultierenden Faxverbindungen zu unseren Remote-Seiten sind instabil (etwa 3 von 10 Faxen konnten überhaupt nicht gesendet werden / führen zu unvollständigen Seiten auf der Empfängerseite), aber ich kann nicht herausfinden, warum - ich kann kein Muster erkennen.

In der Hoffnung, einen Hinweis zu bekommen, wo ich nach einem Fix suchen kann, möchte ich hier ein Protokoll eines unserer Probleme („keine Reaktion auf PPS-Wiederholung“) posten:

Hylafax-Log als GIST auf GitHub

Ich wäre sehr froh, wenn mich jemand auf das/die eigentliche(n) Problem(e) hinweisen könnte – vielen Dank im Voraus!

aktualisieren:

In der Zwischenzeit konnten wir einen weiteren Raspi hinter einer anderen Fax-Leitung einrichten und das gleiche Dokument erfolgreich versenden - das Protokoll sieht bis zu den Zeilen 121 (Fehlerprotokoll) bzw. 153 (Erfolgsprotokoll) ziemlich gleich aus:

Protokoll des erfolgreichen Laufs von einem anderen Raspi

Antwort1

Habe die gleiche Frage in der Mailingliste von Hylafax gepostet und diese Antwort von Lee Howard erhalten:


Der Unterschied liegt in der Anrufweiterleitung und der Verwendung von T.38 für den problematischen Anruf.

Daher weist HylaFAX bei dem problematischen Anruf eine „schlechte Tonqualität“ auf, und schließlich geben ein oder beide Endpunkte den erneuten Versuch auf.

Die Lösung wäre, den Telefondienstanbieter zu wechseln, T.38 zu deaktivieren und auf andere Weise zu versuchen, die Probleme mit der Audioqualität zu beheben.


Darüber hinaus kommentierte er die umgekehrte NSF-Remote-Station-ID mit:


Dies liegt daran, dass das verwendete T.38-Gateway versucht, die NSF zu verschleiern, um zu verhindern, dass der Absender versucht, nicht standardmäßige Funktionen mit ihm auszuhandeln.

Beachten Sie den Unterschied:

29. Juni 09:57:51.03: [ 902]: REMOTE NSF "00 00 00 48 79 6C 61 46 41 58 20 28 74 6D 29 20 56 65 72 73 69 6F 6E 20 35 2E 36 2E 31" 29. Juni 09:57:51.03: [ 902]: NSF Remote-Faxgerät: unbekannt - unbestimmt 29. Juni 09:57:51.03: [ 902]: NSF Remote-Stations-ID: "1.6.5 noisreV )mt( XAFalyH"

... gegen...

29. Juni 10:34:10.55: [24880]: REMOTE NSF „AD 00 55 48 79 6C 61 46 41 58 20 28 74 6D 29 20 56 65 72 73 69 6F 6E 20 35 2E 36 2E 31“ 29. Juni 10:34:10.55: [24880]: NSF Remote-Faxgerät: HylaFAX 29. Juni 10:34:10.55: [24880]: NSF Remote-Stations-ID: „HylaFAX (tm) Version 5.6.1“

Im ersten Beispiel änderte das verwendete T.38-Gateway die ersten drei Bytes des NSF-Signals in „00 00 00“ statt in „AD 00 55“.

Dies ist ein übliches, aber bedauerliches Verhalten von T.38.

verwandte Informationen