Zusammenfassung

  • RFC 3351 wollte Text, Sprache, Video, Relay-Dienste und persönliche Präferenzen als Bestandteile einer SIP-Sitzung behandeln, die sich ohne Neustart des Gesprächs ändern lässt.
  • Das Dokument war eine informative Anforderungssammlung, weder eine standardisierte SIP-Erweiterung noch ein Beleg dafür, dass Geräte und Anbieter die beschriebenen Dienste bereitstellten.

Der entscheidende Satz in RFC 3351 ist eine Architekturvorgabe: Jeder User Agent im Gespräch – auch ein Transcoding-Dienst – sollte einen Medienstrom hinzufügen oder entfernen können, ohne das Gespräch abzubrechen und neu aufzubauen. Ein laufendes Telefongespräch könnte Text dazubekommen; ein Relay könnte hinzukommen, ein Medium umsetzen und sich wieder zurückziehen. Ein Wechsel der Kommunikationsform müsste das Gespräch nicht auf null setzen.

Der im August 2002 veröffentlichte RFC verschob die Frage der Barrierefreiheit von einer Geräteklasse hin zur Behandlung der Sitzung. Ein Nutzerprofil umfasst darin Fähigkeiten und Präferenzen, die SIP übermitteln und für die Sitzungsbehandlung heranziehen soll. Text, Audio und Video können in verschiedene Richtungen kombiniert werden. Ein Strom kann über einen Transcoding-Dienst laufen; ein Gateway kann einen SIP User Agent mit einem älteren Texttelefon verbinden. Die Sitzung wird zum Ort, an dem diese Optionen zusammenkommen.

Der Status des Dokuments muss dabei sichtbar bleiben. RFC 3351 ist Informational und erklärt ausdrücklich, keinen Internetstandard festzulegen. Die Wörter „MUST“ und „SHOULD“ formulieren die gewünschten Anforderungen der Autoren; sie machen daraus keine standardisierte SIP-Erweiterung. Der RFC zertifiziert keine Implementierung und zählt auch nicht, wie viele Dienste zugänglich wurden. Seine Dialoge sind Entwurfsszenarien, keine Bestandsaufnahme des Betriebs.

Ein Nutzerprofil schafft zudem ein Spannungsfeld beim Datenschutz. Es kann helfen, den passenden Kommunikationsweg auszuwählen, zugleich aber etwas über die Person verraten. RFC 3351 stellt sich deshalb vor, dass der Gesprächspartner nicht allein wegen eines Relays erfahren muss, dass die anrufende Person taub ist. Vermittler sollen ihre Vertraulichkeitsregeln offenlegen; Anbieter sollen ermöglichen, Fähigkeiten und Präferenzen nicht in jeder Transaktion öffentlich zu machen. Barrierefreiheit betrifft also nicht nur den Transport von Text, sondern auch das Wissen, die Speicherung und die Offenlegung durch den Dienst.

Kosten und Auswahl behandelt der RFC ungewöhnlich konkret. Ein User Agent soll den Inhalt eines Medienstroms erkennen, Transcoding-Dienste nach Fähigkeit und Richtlinien vergleichen und Alternativen finden können. Vor Gesprächsbeginn sollen nach Möglichkeit Minutenpreis und Mindestgebühr sichtbar sein. In einem Szenario bietet ein Radiosender keinen Textstrom; ein Transcoding-Anbieter lehnt die Umwandlung des Audios ab, weil sie seine Ressourcen überlasten könnte. Der Kommunikationspfad hat eine betriebliche Grenze. Signalisierung macht aus einer nicht verfügbaren Leistung keine Garantie.

Die Szenarien gehen über Untertitel hinaus. In einem bleibt das Telefongespräch offen, während ein Relay Sprache in Text und die getippte Antwort wieder in Sprache umsetzt. In einer Konferenz werden Sprache, Text und Gebärdensprache passend zu den unterschiedlichen Präferenzen der Teilnehmenden verkettet. Auch ein sprachgesteuertes Telefonmenü kann über einen Vermittler einen Textweg erhalten. Die Entwürfe stellen die Wahl der Nutzer in den Mittelpunkt; jede zusätzliche Umwandlung bringt jedoch einen Anbieter, eine Richtlinie, mögliche Kosten und eine weitere Grenze für den Datenfluss mit sich.

Die späteren RFCs zeigen eine Entwicklung der Spezifikationen, nicht den universellen Erfolg. RFC 4103 definierte ein RTP-Format für T.140-Echtzeittext und empfahl Redundanz, um einige verlorene Zeichen wiederherzustellen. RFC 5194 entwickelte einen genaueren SIP/IP-Rahmen für Text, Transcoding, Darstellung und Zusammenschaltung und verwies bei Relay-Diensten auf RFC 3351. RFC 4504 empfahl SIP-Telefonen, die Barrierefreiheitsanforderungen aus RFC 3351 zu unterstützen.

Viel später legte RFC 8865 T.140 über zuverlässige, geordnete WebRTC-Datenkanäle fest; RFC 9071 behandelte gemischten RTP-Text in Mehrparteiengesprächen und aktualisierte RFC 4103. Jeder Text präzisiert einen Teil des Pfads. Keiner belegt, dass alle Endgeräte, Anbieter oder Notdienste ihn anbieten.

Darin liegt der historische Beitrag: Der Wechsel des Mediums sollte keinen neuen Anruf erzwingen, und die Person sollte mitbestimmen können, wie der Wechsel abläuft. Eine technisch erweiterbare Sitzung kann trotzdem unerreichbar, zu teuer, inkompatibel oder von einem Anbieter abgelehnt sein. Ein hilfreiches Profil kann zugleich sensible Daten preisgeben. RFC 3351 brachte Kontrolle, Kosten und Vertraulichkeit in die Diskussion über den Gesprächsaufbau. Es behauptete nicht, dass dieser Ausgleich bereits erreicht sei.

Quellen: RFC 3351 · RFC-3351-Eintrag · Datatracker-Eintrag zu RFC 3351 · RFC 2119 · RFC 8174 · SIP: Session Initiation Protocol, RFC 3261 · SDP-Angebots-/Antwortmodell, RFC 3264 · RTP-Format für Gesprächstext, RFC 4103 · Rahmen für Echtzeittext über SIP, RFC 5194 · Anforderungen an SIP-Telefone, RFC 4504 · T.140-Text über WebRTC-Datenkanäle, RFC 8865 · RTP-Mischung von Echtzeittext für mehrere Teilnehmer, RFC 9071 · Minimale Anfangsspezifikation, lokalisierte spätere Entscheidung und freiwillige Übernahme · Vorrang von laufendem Code