Zusammenfassung

  • Strict vermeidet T.38-Versuche ohne verwertbaren Fähigkeitsnachweis, kann jedoch ein tatsächlich fähiges Gegenüber ablehnen. Loose toleriert fehlende Deklarationen, kann aber gegen ein wirklich unfähiges Gegenüber umschalten. Die Wahl ist eine Fehlerpolitik.
  • Eine ausgelassene Faxoption besitzt nicht die Bindung einer ausdrücklich wiederholten Anforderung. Ein ModifyConnection kann grün werden, obwohl T.38 nicht mehr aufgerufen wird; mit explizitem t38 müsste dieselbe Änderung scheitern.
  • Auswahl und Senden folgen unterschiedlichen Zeitbezügen. Verfahrensereignisse wiederum beweisen keinen Dokumenterfolg: t38(stop) ist kein Zustellbeleg.

Strict behandelt fehlende Evidenz als Grenze

Im Call-Agent-gesteuerten Strict-Modus muss die aktuelle Entscheidung durch passende Informationen beider Seiten getragen sein. Eine RemoteConnectionDescriptor im aktuellen Befehl kann image/t38 oder eine geeignete Fähigkeitsdeklaration enthalten.

Fehlt dieser Beleg, wird T.38 nicht einfach aufgrund früherer Erfahrung oder einer Vermutung gewählt. Das verhindert einen Wechsel, den das Gegenüber möglicherweise nicht verarbeiten kann.

Die Schutzwirkung hat einen Preis. Ein Gerät kann T.38 beherrschen, aber seine Fähigkeit nicht über den erwarteten Mechanismus ausdrücken. Strict verwechselt dann fehlende beweisbare Fähigkeit mit fehlender technischer Fähigkeit und erzeugt ein falsch negatives Ergebnis.

Das ist kein Implementierungsdetail, das ein grünes Dashboard wegmitteln darf. Die Organisation entscheidet, ob ein sichtbarer Abbruch ohne Nachweis besser ist als ein unbewiesener Versuch. Diese Entscheidung braucht eine benannte Risikoklasse und eine verantwortliche Stelle.

Loose verschiebt das Risiko auf den Versuch

Loose kann T.38 auch dann verwenden, wenn die formale Fähigkeitsanzeige fehlt. Damit rettet es Verbindungen zu Gegenstellen, die technisch geeignet sind, ihre Eignung aber nicht wie erwartet deklarieren.

Genau dieselbe Offenheit kann gegen ein tatsächlich ungeeignetes Gegenüber wirken. Der Umschaltversuch scheitert und kann das Fax kosten. Das falsch negative Strict-Ergebnis wird gegen ein potenziell falsch positives Loose-Ergebnis getauscht.

RFC 5347 behauptet ausdrücklich keine allgemein gute Antwort. Endgerätebestand, Deklarationsqualität, Fehlertoleranz und Geschäftsfolgen bestimmen die Wahl.

Ein Betrieb sollte daher Quoten nicht nur nach Strict und Loose trennen, sondern auch nach nachträglich bestätigter Gegenstellenfähigkeit. Sonst bleibt unsichtbar, ob Strict wertvolle Risiken abwehrt oder überwiegend brauchbare Sitzungen ablehnt.

Fähigkeit ist nicht Erlaubnis

Eine SDP-Fähigkeitsdeklaration kann aktuelle und latente Möglichkeiten nennen. Die Aussage „dieses Gerät kann T.38“ ist nicht die Aussage „der Call Agent erlaubt T.38 in diesem Befehl“.

Wenn eine Automatisierung aus Fähigkeit unmittelbar Erlaubnis ableitet, erhält Entdeckungsinformation Entscheidungsgewalt. Umgekehrt erklärt eine explizite Erlaubnis ohne damaligen Fähigkeitsbeleg nicht, warum der Befehl sicher angenommen wurde.

Der Nachweis muss deshalb vier Dinge verbinden: was angekündigt wurde, von wem, zu welchem Zeitpunkt und für welchen aktuellen Befehl die Nutzung ausdrücklich verlangt war.

Ein zeitloses Feld „T.38 unterstützt“ genügt nicht. Es verdeckt sowohl veraltete Anzeigen als auch die Grenze zwischen technischer Möglichkeit und aktueller Autorität.

Auslassung kann eine strenge Pflicht leise entkräften

Das zentrale Beispiel beginnt mit einer erfolgreich unter T.38 Strict aufgebauten Verbindung. Später enthält ein ModifyConnection eine RemoteConnectionDescriptor ohne T.38-Unterstützung.

Wird die Fax-LocalConnectionOption ausgelassen, gelingt der Befehl. Der bestehende Wert bleibt erhalten, doch seine Erfüllung ist keine Bedingung des aktuellen Erfolgs. Bei Faxerkennung wird T.38 nicht mehr aufgerufen; nopfax(start) folgt.

Wiederholt der Call Agent t38 ausdrücklich, muss derselbe Befehl scheitern. Fehler 532 wird empfohlen, wenn kein angefordertes Verfahren erfüllbar ist. Das Rot schützt die benannte Anforderung.

Ein Konfigurationsvergleich, der nur Vorher- und Nachherwert zeigt, meldet „unverändert“. Tatsächlich hat sich die Autoritätsstärke geändert. Die Präsenz des Feldes im Befehl ist deshalb selbst ein Beweisdatum.

Auswahl und Medienversand haben zwei Uhren

Für die Auswahl im aktuellen Befehl zählt nur eine RemoteConnectionDescriptor, die dieser Befehl mitführt. Eine früher empfangene Beschreibung kann keine heutige Auswahl autorisieren.

Vor dem tatsächlichen Senden gilt eine andere Regel. Die zuletzt empfangene entfernte Beschreibung muss die passende image/t38-Medienzeile und einen unterstützten Transport enthalten. Das Verfahren darf bereits beginnen, die Pakete müssen aber auf die Freigabe warten. Bei Timeout endet es mit stop oder failure.

Auswahl beantwortet, was der aktuelle Befehl etablieren kann. Versand beantwortet, was jetzt die Schnittstelle verlassen darf. Eine spätere Signalisierung kann die zweite Antwort verändern, ohne die historische Auswahlentscheidung neu zu schreiben.

Ein einziges Feld „letztes SDP“ löscht diese Kausalität. Erforderlich sind die Beschreibung pro Befehl, die jüngste Beschreibung an jedem Sendepunkt, Wartebeginn, Freigabe, erstes Paket und Timeout.

Die Optionsliste besitzt nichtlineare Semantik

t38 steht für Strict unter Kontrolle des Call Agent, t38-loose für die lockere Variante, gw für die Delegation an das Gateway und off für kein besonderes Faxverfahren abgesehen von lokalen Anpassungen.

Eine Semikolonliste wirkt wie eine gewöhnliche Prioritätsfolge. t38-loose und off sind jedoch immer unterstützbar. Alles dahinter ist unerreichbar.

gw hat einen Sonderfall: Würde die Gateway-Auswahl zu keiner besonderen Behandlung führen, kann ein späteres Nicht-off-Verfahren geprüft werden. Eine reine Tokenvalidierung erkennt weder tote Zweige noch diesen Durchlauf.

Policy-Werkzeuge müssen Reihenfolge, Erreichbarkeit, Ablehnungsgründe, Gateway-Durchlauf und effektives Ergebnis darstellen. Eine längere Liste ist kein Beweis für mehr Ausfallsicherheit.

Delegation verschiebt den Erkenntniszeitpunkt

Im Gateway-Modus existiert eine besondere Behandlung nur, wenn beide Seiten dieselbe Methode unterstützen und sie im ausgetauschten SDP anzeigen. Der Hersteller bestimmt die Details. Ohne gemeinsame Methode findet keine Sonderbehandlung statt.

Der Call Agent erfährt das möglicherweise erst beim Faxbeginn durch nopfax(start). Der frühere grüne Befehl war ein akzeptierter Delegationsauftrag, kein Startbeleg.

Beginnt eine Gateway-Methode tatsächlich, liefert gwfax(start) den Beleg. Danach sollte der Call Agent widersprechende Befehle vermeiden, bis das Verfahren endet.

Delegation verlangt somit Startbestätigung und eine konfliktfreie Kontrollperiode. Die bloße Einstellung gw beweist weder gemeinsame Methode noch Ausführung.

Stop ist kein Dokumenterfolg

t38(start) meldet Erkennung und Start des Call-Agent-gesteuerten Verfahrens. t38(stop) meldet dessen Ende ohne vom Gateway erkannten Fehler. RFC 5347 warnt ausdrücklich, dass dies nicht zwingend erfolgreiche Faxübertragung bedeutet.

Seitenzahl, Integrität, Annahme durch die entfernte Anwendung, richtiger Empfänger und menschlicher Empfang bleiben unbelegt. t38(failure) kennzeichnet ein abnormales Ende; das Ausbleiben dieses Fehlers füllt die fehlenden Geschäftsbelege nicht.

Auch gwfax beschreibt nur den Lebenszyklus der delegierten Methode. nopfax(start) besitzt keine Stopform, weil ein Modus ohne Sonderbehandlung das Faxende nicht aus dem Medium ableiten soll.

Verfahrensstatus und Dokumentstatus benötigen getrennte Felder und Quellen. Automatisches Übertragen von stop nach delivered überschreitet die Beobachtungsgrenze des Gateways.

Selbst Faxerkennung kann falsch positiv sein

Mindestens die V.21-Präambel muss erkannt werden. Die Erkennung des T.30-CNG-Tons ist optional. Das RFC nennt Berichte über Modems, die CNG in Nicht-Fax-Anrufen erzeugten, und empfiehlt eine Abschaltmöglichkeit.

Damit kann ein autorisiertes, korrektes und sauber beendetes Verfahren auf einer falschen Ausgangsbeobachtung beruhen. Korrekte Folgeschritte beweisen rückwärts kein Faxdokument.

Ursprungs- oder Zielgateway, auch beide gleichzeitig, können den Wechsel anstoßen. Erkennungsquelle, Signal, Initiator, Zeitpunkt und Auflösung gleichzeitiger Starts gehören in die Spur.

Erkennungsvertrauen und Verfahrensautorität dürfen nicht verschmelzen. Ein starkes Signal erteilt keine verweigerte Erlaubnis; eine klare Erlaubnis macht ein falsches Signal nicht wahr.

Portstabilität braucht expliziten Zustand

Die Wiederverwendung von IP-Adresse und Port zwischen RTP-Audio und T.38 reduziert Schwierigkeiten mit QoS, NAT und Firewalls. Der Fünfertupel identifiziert dann aber nicht dauerhaft den Medientyp.

Explizite Signalisierung bestimmt das erwartete Format. Der Empfänger validiert dagegen und soll nicht durch Paketinspektion opportunistisch demultiplexen.

Empfohlene Toleranz gegenüber Groß-/Kleinschreibung bei UDPTL- und T.38-Attributen oder historischen Booleschen Fehlformen unterstützt Interoperabilität, beweist aber keine Policy.

Paket- und Oktettzähler umfassen Fax, während Jitter- und mittlere Verzögerungsmessung während Fax ausgesetzt werden können. Gerade während des Wechsels kann Messlücke entstehen. Signalisierungsbelege bleiben daher unverzichtbar.

Der historische Status begrenzt die Aussage

RFC 5347 erschien im Oktober 2008 als Informational und ist kein Internet Standard. Die Errata-Suche des RFC Editor führt sechs für eine Dokumentaktualisierung zurückgehaltene Meldungen. Dieser Status gehört zu jeder belastbaren Auslegung.

Das Dokument beweist weder heutiges Produktverhalten noch aktuelle Verbreitung. Es sagt auch nicht, dass jedes erfolgreiche Fax T.38 benötigt.

Sein dauerhafter Wert liegt im expliziten Risikotausch. Strict, Loose, Delegation und Off sind nicht bloß technische Modi; sie entscheiden, wann Unsicherheit sichtbar wird, wer handeln darf und welche Aussage am Ende unbelegt bleibt.