Faxempfang funktioniert nicht

Hallo,

seit 529 ? oder auch schon vorher und nur zu diesem FAX-Absender ?

Du musst dieses problem

"DISCONNECT_B3_IND (0x3314) Disconnect during fax transfer (remote abort)"

lösen, dann kommt auch ein Fax vollständig an.

mit KI-Hilfe, ohne selbst nachzudenken:

gesicherte Fakten (CAPI‑2.0‑Spezifikation, B3‑Protokoll T.30 Fax G3):

• DISCONNECT_B3_IND = Die Datenverbindung der Schicht 3 (der eigentliche Faxkanal) wurde beendet.
• Reason 0x3314 = „Disconnected during transfer (remote abort)“ – die Verbindung wurde während der Seitenübertragung von der Gegenstelle abgebrochen, also nicht schon beim Verbindungsaufbau/Training. Die Faxgeräte hatten sich also bereits erfolgreich verständigt.

Typische Ursachen (Hypothesen, nicht aus der Meldung selbst ableitbar):

1. Die Gegenstelle hat aufgelegt, weil sie zu viele fehlerhafte Zeilen/Seiten empfangen hat (z. B. DCN nach RTN/Fehlerquote) – im deutschen All‑IP‑Netz die häufigste Ursache: Paketverlust/Jitter bei G.711‑Passthrough ohne T.38.
2. Papierstau, Speicher voll oder manueller Abbruch am Empfangsgerät.
3. Zeitüberschreitung bei der Gegenseite (Timer T2/T5), etwa wenn ECM‑Wiederholungen zu lange dauern.
4. Inkompatibilität bei hoher Baudrate (14.400 Bd) – Abhilfe oft: Rate auf 9.600 begrenzen, ECM ein/aus testen.

Wenn der Fehler reproduzierbar bei einer bestimmten Gegenstelle auftritt, spricht das für Punkt 1 oder 4; tritt er bei vielen Empfängern auf, eher für die eigene Leitung (VoIP‑Qualität, T.38‑Einstellung am Router).

und weiter was alles so ki-basiert geht:

Was das Protokoll tatsächlich zeigt (Fakten):

1. Eingehendes Fax (CONNECT_IND, Called Number 38, Anrufer 3364750599, Absender-ID „Maler GmbH“). Verbindungsaufbau und Training waren erfolgreich: 14.400 Bd, ECM, Format 0 (SFF).
2. Erster Datenblock kommt an: DATA_B3_IND (0x0000) Size=1024.
3. Sofort danach sendet die eigene Software DISCONNECT_B3_REQ – ohne vorher DATA_B3_RESP (0x0000) zu quittieren. Der Abbruch der B3‑Verbindung wurde also lokal eingeleitet, nicht von der Gegenstelle.
4. Ein zweiter, kleiner Block (52 Byte) läuft noch ein, dann meldet der Treiber DISCONNECT_B3_IND 0x3314. Der Reason-Code „remote abort“ ist hier irreführend: Wenn die Applikation bereits DISCONNECT_B3_REQ geschickt hat, liefert der CAPI‑Treiber beim anschließenden Abbruch der T.30‑Sitzung oft diesen Code, weil die Gegenstelle auf den lokalen Abbruch mit DCN reagiert.
5. Danach DISCONNECT_IND 0x3301 „Protocol error layer 1“ – Schicht 1 (physikalisch: S0/UP0‑Bus bzw. bei VoIP-Emulation die Leitungsanbindung) ist weggebrochen.
6. ISDN_API_RELEASE / ISDN_API_REGISTER mit derselben ApplID: Die Fax-Applikation hat sich beim CAPI komplett ab- und neu angemeldet.

Schlussfolgerung (gesichert aus der Sequenz): Nicht die Gegenstelle „Maler GmbH“ hat abgebrochen, sondern Ihre Fax-Software hat nach dem ersten 1‑kB‑Block die Verbindung selbst beendet und anschließend die CAPI neu initialisiert.

Zur Eingrenzung:

• Tritt 0x3301 auch bei anderen Faxen oder ohne laufende Übertragung auf? → Leitung/Hardware.
• Ereignisprotokoll der Fax-Software / Windows-Ereignisanzeige zum Zeitpunkt 03.08.2026 14:11:52 prüfen (Dienst-Neustart, Ausnahme).
• CAPI‑Treiber und Fax-Software (Version) sowie Art der Anbindung (echtes ISDN, FRITZ!Box-CAPI, VoIP‑Gateway) nennen – dann lässt sich die Hypothese schärfen.