Zusammenfassung

  • RFC 5194 verlangt die Möglichkeit eines Echtzeittext-Notrufs und berücksichtigt Relay-Dienste. Das erfolgreiche Routing beweist weder Relay-Bereitschaft noch einen sendenden, empfangenden und darstellenden Textkanal.
  • Ein belastbarer Ablauf hält Zielannahme, Relay-Auswahl, Medienaushandlung, erstes gesendetes und dargestelltes Zeichen, Verlustzustand und dauerhafte Zweiwegetauglichkeit auseinander. Der früheste grüne Zustand darf die späteren Oberflächen nicht vertreten.

Die Kennzahl schloss zu früh

Die Zielstelle hatte schnell reagiert. Für klassische Telefonie wäre „angenommen“ eine wichtige Marke. Im vorliegenden Ablauf wurde sie zur Schlussmarke für einen Dienst, dessen entscheidendes Medium noch nicht bereit war.

RFC 5194 behandelt Echtzeittext als zeichenweise Konversation. Zeichen sollen möglichst unmittelbar nach der Eingabe gesendet werden; das Puffern ganzer Zeilen erfüllt die Anforderungen an die Zeichenverzögerung nicht. Ein Textkanal existiert daher nicht schon deshalb, weil eine Session ihn beschrieben hat. Er muss Zeichen tatsächlich durch die gesamte Kette tragen und darstellen.

Der Notruf macht die begriffliche Abkürzung sichtbar, aber sie betrifft jede Sitzung. Ein Ziel kann erreicht, ein SIP-Dialog etabliert und ein Medium ausgehandelt sein, während der Nutzer noch keine nutzbare Kommunikation hat.

Mehrere Uhren statt einer Antwortzeit

Der operative Datensatz braucht mehrere Zeitpunkte: Beginn des Routing, Annahme durch das Ziel, Relay angefragt und bereit, Text angeboten und angenommen, erstes Zeichen eingegeben, gesendet, empfangen und dargestellt. Danach folgen Kontinuität und Ende der Zweiwegekommunikation.

RFC 5194 bezeichnet eine Sekunde Ende-zu-Ende als gut, nennt wahrnehmbare Verbesserungen bis 300 Millisekunden und hält bis etwa zwei Sekunden für möglicherweise akzeptabel. Das ist kein allgemeines modernes Rechts- oder Vertrags-SLA. Es zeigt, dass sich die relevante Uhr am Zeichen orientiert und nicht am Aufbau der Verbindung.

Ein nach acht Sekunden freigegebener Textblock kann das Netz in Millisekunden durchqueren. Eine reine Transportmessung bewertet den Pfad als schnell und lässt die eigentliche Wartezeit verschwinden. Eingabe-, Sende-, Ankunfts-, Decodier- und Renderzeit müssen deshalb verbunden werden.

SIP koordiniert, aber beobachtet nicht alles

SIP etabliert den Dialog. Offer/Answer und SDP beschreiben Adressen, Ports und Formate. Diese Belege sind unverzichtbar. Sie bestätigen eine Übereinkunft, nicht den laufenden Zeichentransport oder die Darstellung.

Auch ein erfolgreicher Audiokanal ist kein Zeuge für Text. Sprache, Video und Echtzeittext können in einer Session gemeinsam auftreten und dennoch unabhängig ausfallen. Ein globales connected muss auf medienbezogene Zustände verweisen: ausgehandelt, erstes Zeichen gesendet, erstes Zeichen empfangen, Sequenzkontinuität, offener Verlust und Renderfortschritt.

Die Stille eines Textstroms bleibt mehrdeutig. Sie kann bedeuten, dass niemand tippt, dass der Sender puffert, dass der Transport blockiert oder der Renderer steht. Die Plattform muss keine Nutzeraktivität erfinden; sie muss die technischen Zustände getrennt erhalten.

Redundanz ist keine Vollständigkeitsgarantie

RFC 4103 überträgt T.140 über RTP und kann mit dem RFC-2198-Format kürzlich gesendeten Text redundant beilegen. Ein späteres Paket kann damit eine frühere Lücke reparieren. Gerade im Notruf ist das wertvoll, weil ein verlorenes Zeichen eine Zahl, einen Ort oder eine Verneinung verändern kann.

text/red als ausgehandeltes Format beweist aber weder seine Nutzung noch vollständige Wiederherstellung. Der Empfänger muss festhalten, welche Sequenz fehlte, welche Redundanz welche Zeichen zurückbrachte und was ungeklärt blieb. RFC 5194 erwartet bei verbleibendem Verlust eine Textverlustanzeige.

Eine Oberfläche, die die Lücke einfach schließt, erzeugt eine Aussage mit höherer Gewissheit als die Daten. Das Archiv muss die Verlustmarke und ihre Herkunft erhalten, statt sie als unschöne Formatierung zu entfernen.

Darstellung ist ein eigener Ausgang

T.140 umfasst internationale Zeichen sowie Zeilenwechsel, Löschen und Alarmierung. Das Empfangsprotokoll und der Bildschirm können deshalb unterschiedliche Wahrheiten besitzen. Ein Renderer kann pünktliche Zeichen bis zum Satzzeichen zurückhalten. Ein Archiv kann gelöschten Text wieder aufnehmen. Eine Zeichensatzkonvertierung kann einen Namen beschädigen.

Sinnvoll sind drei Aufzeichnungen: empfangene Ereignisse, dargestellte Ereignisse und das spätere Transkript. Das Transkript ist nützlich, aber eine Projektion. Es darf nicht allein beantworten, was die Person wann sah.

Relay und Gateway sind keine transparenten Leitungen

RFC 5194 beschreibt die Zusammenarbeit mit älterer PSTN-Texttelefonie, mobilen Textdiensten und Instant Messaging. Solche Grenzen können Rate, Duplexverhalten, Zeichenrepertoire und Pufferung ändern. Die IM-Passage beschreibt ausdrücklich das Sammeln einzelner Zeichen bis zu einem Auslöser.

Diese Anpassung kann notwendig sein. Sie benötigt dennoch einen Nachweis: Eingangs- und Ausgangsprotokoll, Pufferregel, Rate, Duplexänderung, Zeichenzuordnung, Verlustdarstellung und Version. Sonst erscheint eine lokal erzeugte Verzögerung als Netzwerkproblem oder eine Nachrichtenblase als unveränderter Echtzeitstrom.

Für ein Relay gilt dieselbe Verantwortung. „Ausgewählt“ ist nicht „bereit“, und „bereit“ ist nicht „erste erfolgreiche Zweiwegekommunikation“. Die Rollen dürfen in der Ereignisakte verbunden, aber nicht zusammengezogen werden.

Gegen den Einwand der Überinstrumentierung

Ein naheliegender Einwand lautet, diese Belege seien für eine einfache Textverbindung zu aufwendig. Doch die benötigten Oberflächen existieren bereits: Session, RTP-Folge, Decoder, Renderer und Gateway kennen ihren eigenen Zustand. Aufwendig wird es erst, wenn ein späteres Team versucht, aus einer einzigen grünen Kennzahl den verlorenen Ablauf zu rekonstruieren.

Der vorgeschlagene Receipt ist keine von RFC 5194 vorgeschriebene Wire-Syntax. Er ist eine operative Schlussfolgerung: Sitzung und Medienbeschreibung, Stream und Teilnehmer, Zeiten von Eingabe bis Anzeige, primäre und reparierte Ankunft, Restverlust, Nutzeranzeige, Status je Medium und jede Gateway-Transformation.

Führung und Wirklichkeitsschichten

Die Wirklichkeitsschichten von Heng Lu begrenzen die Aussagekraft der Symbole. geroutet spricht für den Weg zum Ziel. angenommen spricht für die Gegenstelle. ausgehandelt spricht für eine Medienbeschreibung. dargestellt spricht erstmals für die Oberfläche des Nutzers. Kein früheres Ereignis darf das spätere erfinden.

Die minimale Anfangsspezifikation schützt die interoperable Bedeutung der Zeichenkonversation. Lokale Systeme dürfen Relay, UI, Speicherung und Wiederherstellung verbessern. Running-Code-Primacy verlangt nur, dass der tatsächlich laufende Zeichenpfad mehr Autorität besitzt als das Badge, das ihn zusammenfasst.

Sources

  1. RFC 5194 HTML
  2. RFC 5194 Text
  3. RFC-5194-Informationsseite
  4. Datatracker RFC 5194
  5. RFC-5194-Historie
  6. RFC-5194-Referenzen
  7. RFC-5194-Errata
  8. RFC 4103
  9. RFC-4103-Informationsseite
  10. RFC 9071
  11. RFC-9071-Informationsseite
  12. RFC 4351
  13. RFC 3550
  14. RFC 2198
  15. RFC 3261
  16. RFC 3264
  17. RFC 8866
  18. Heng Lu — Wirklichkeitsschichten
  19. Heng Lu — minimale Anfangsspezifikation
  20. Heng Lu — Primat laufenden Codes