Zusammenfassung

  • RFC 5370 spezifiziert das Konferenzbrückenmodell für SIP-Transcoding. A sendet T ein multipart-INVITE mit SDP und einer Empfängerliste; die Liste enthält genau eine URI für B.
  • T ist ein B2BUA und kein Proxy. Es interpretiert beide Körper, erzeugt eine eigene Sitzungsbeschreibung und eröffnet eine neue Transaktion zu B. Medienfähigkeit und Zielautorität dürfen deshalb nicht in einem allgemeinen „Call“-Datensatz verschwinden.
  • Ein gleicher finaler Status auf beiden Seiten ist eine von T erzeugte Korrelation. Geht die vorläufige Antwort verloren, braucht A History-Info, um eine Ablehnung durch T von einer Ablehnung durch B zu unterscheiden.

Eine Nachricht enthielt zwei Steuerungsobjekte

Beim Aufruf durch den Anrufer baut A eine Sitzung zu T auf und liefert gleichzeitig die URI von B. Dazu verwendet A die Verfahren für anfrageenthaltene Listen aus RFC 5366.

Der Nachrichtenkörper enthält SDP und einen Teil mit der Disposition recipient-list. SDP beschreibt A gegenüber T. Die Liste enthält B als Ziel für eine weitere Aktion.

Die gemeinsame Verpackung kann zu einem gefährlichen Kurzschluss führen: Wer die Nachricht als Ganzes „Medienangebot“ nennt, übersieht, dass ein Teil davon T zum Erzeugen einer neuen Anfrage ermächtigt.

Ein Beleg muss beide Objekte getrennt benennen, hashen und einer Entscheidung zuordnen. Nur dann lässt sich später feststellen, ob die Medienparameter oder das Ziel verändert wurden.

Die Liste war kein unverbindlicher Hinweis

T empfängt die URI nicht zur Anzeige. Es verwendet sie, um ein INVITE zu erzeugen. Die Liste bestimmt also die Oberfläche, auf der T als neuer Handelnder auftritt.

RFC 5370 begrenzt diese Liste auf eine URI. Enthält sie mehr, soll T 488 mit dem Hinweis zurückgeben, dass höchstens eine URI zulässig ist.

Die Begrenzung definiert das Zwei-Parteien-Transcodingmodell. Sie widerspricht nicht Mehrparteienkonferenzen nach RFC 5366, sondern zieht für diesen Dienst eine engere Autoritätsgrenze.

Zielanzahl, exakte URI und Herkunft der URI gehören deshalb in den dauerhaften Datensatz. „Liste erfolgreich verarbeitet“ reicht nicht aus.

Integrität musste das Handlungsziel umfassen

Die Sicherheitsbetrachtung betont die Integrität der URI-Liste und verweist auf Mechanismen wie S/MIME oder TLS. Diese Aussage lässt sich nur verstehen, wenn die Liste als Auftrag betrachtet wird.

Ein unverändertes SDP bei manipulierter Liste würde korrekte Codecparameter an den falschen Empfänger senden. Die Medienbeschreibung wäre integer, die Handlung aber nicht autorisiert.

Der Integritätsnachweis muss den tatsächlichen Schutzbereich, die geprüften Bytes und das Prüfergebnis nennen. Ein allgemeines Feld „encrypted=true“ sagt nicht, ob gerade die Zielliste erfasst war.

Nach der Terminierung bei T entsteht auf der T–B-Strecke ein eigener Schutzkontext. Die Sicherheit der A–T-Verbindung wandert nicht automatisch mit.

T interpretierte statt weiterzuleiten

RFC 5370 nennt T ausdrücklich einen B2BUA, nicht einen Proxy. Das ausgehende INVITE gehört zu einer anderen Transaktion als das eingehende.

T erstellt außerdem ein SDP passend zur angebotenen Transcodingleistung. Bei einer Audio-Codec-Inkompatibilität beschreibt T seine eigenen unterstützten Codecs gegenüber B.

Damit trifft T Entscheidungen über Ziel, Darstellung, Medienangebot und später die Rückmeldung. Es ist nicht bloß Transport für die zwei Körperteile.

Ein internes Korrelationskennzeichen darf beide Strecken verbinden. Es darf ihre Transaktions-, Dialog- und Authentisierungsidentitäten nicht ersetzen.

From transportierte Darstellung, nicht Paketursprung

T muss den ausgehenden From-Wert aus dem eingehenden bilden und dabei die Datenschutzanforderungen beachten. Der tag-Parameter wird nicht übernommen.

B kann deshalb A als dargestellten Anrufer sehen, obwohl T das empfangene Paket erzeugt hat. Darstellung und Transaktionsursprung sind bewusst getrennt.

Auch authentisierter Nutzer, Autorisierungsentscheidung, dargestellter Absender und eine überprüfbare Aussage über den ursprünglichen Sender bleiben verschiedene Belege.

RFC 5370 zitierte dafür den damaligen SIP-Identity-Mechanismus aus RFC 4474; RFC 8224 ersetzte ihn später. Daraus folgt keine Aussage über die heutige Konfiguration eines konkreten Systems.

Gleicher Status war eine neue Aussage

Wenn T eine endgültige Antwort von B empfängt, erzeugt es eine neue endgültige Antwort für A. Diese soll denselben Statuscode haben.

Ein 603 Decline auf beiden Seiten ist daher nicht dasselbe Antwortobjekt. T übernimmt eine Ergebnisklasse in eine andere Transaktion.

Geht das zuvor gesendete 183 Session Progress verloren, kann A aus dem 603 nicht erkennen, ob T die erste Anfrage ablehnte oder B die zweite.

Statusgleichheit unterstützt Korrelation. Sie beweist weder Ereignisidentität noch den Entscheidungsträger.

History-Info schützte die Zurechnung

RFC 5370 nennt History-Info zwischen T und A als Lösung der Mehrdeutigkeit. Die Historie ergänzt den Weg, auf dem das Ergebnis entstanden ist.

Der Fall zeigt, dass vorläufige Nachrichten Beweiswert besitzen können. Das 183 deutet an, dass T mit der weiteren Bearbeitung begonnen hat. Sein Verlust entfernt eine wichtige Trennlinie.

Der Originaltext verwies auf RFC 4244; RFC 7044 aktualisierte später den History-Info-Kontext. Die Nachfolgepublikation beweist nicht, dass eine bestimmte Sitzung ausreichende Historie transportierte.

Wenn der Nachweis fehlt, muss die Herkunft als unbekannt gelten. Wahrscheinlichkeitswissen darf nicht als Protokollbeleg gespeichert werden.

Der verworfene Entwurf zeigte beide Entscheidungen

Eine Alternative hätte T zunächst mit 200 OK gegenüber A antworten lassen. T hätte B unabhängig eingeladen, und A hätte den Ausgang über das Conference Event Package verfolgt.

Das hätte die Dienstannahme und die Zielannahme sichtbar getrennt. Der Preis wären mehr Nachrichten, höhere Komplexität und längere Aufbauzeit gewesen.

Der RFC verwarf diese Variante für den Transcodingdienst. Das gewählte Modell sparte Koordination und benötigte dafür History-Info zur Fehlerzuordnung.

Wer später Historie und Provisorien aus Kostengründen entfernt, streicht genau die Evidenz, die den vereinfachten Ablauf tragfähig macht.

Die Opt-in-Ausnahme hing an der Listenform

URI-Listendienste können eine Anfrage vervielfachen und unerwünschte Kommunikation erzeugen. RFC 5370 verlangt für diesen speziellen Dienst dennoch keine Opt-in-Listen.

Die Begründung besteht aus drei Tatsachen: T erzeugt nur ein INVITE; A trägt die ihm bekannte URI von B selbst ein; die Identität des Anrufers ist im ausgehenden Request vorhanden.

Die Ein-Ziel-Liste verhindert quantitative Verstärkung. Die vom Anrufer benannte URI verhindert eine verdeckte Zielübersetzung. Die Identitätsdarstellung macht die Quelle für B erkennbar.

Erweitert ein Produkt Gruppen, löst unbekannte Ziele auf oder unterdrückt die Identität vollständig, ist die ursprüngliche Analyse nicht mehr unverändert anwendbar.

Authentisierung genehmigte nicht jedes Ergebnis

T muss Nutzer authentisieren und autorisieren. Das kontrolliert, wer die Diensthandlung auslösen darf.

Es beweist nicht, dass T das richtige SDP erzeugte, eine korrekte Transformation lieferte, nur nötige Medien sah oder Daten nachher löschte.

Auch kryptografische Referenzen des Jahres 2008 müssen historisch gelesen werden. RFC 5246 und die damaligen S/MIME- und Identity-Dokumente sind kein aktueller Konfigurationsbeleg.

Ein heutiger Nachweis muss das tatsächlich verhandelte Verfahren, die Endpunkte, die Richtlinie und das Prüfergebnis ausweisen.

Die 302-Antwort enthielt erneut einen Auftrag

Kann B das SDP nicht akzeptieren, darf es mit 302 Moved Temporarily zu T umleiten. Der Contact enthält T sowie einen ?body=-Parameter mit einer Empfängerliste für B.

Die Antwort führt die Transcodierung nicht selbst aus. A beendet den ersten Versuch, dekodiert und prüft den komplex escaped Body und entscheidet über ein neues INVITE.

Der RFC merkt an, dass 3pcc für den Aufruf durch den Angerufenen einfacher ist. Das Einbetten eines Körpers in eine URI schafft zusätzliche Parser- und Autoritätsgrenzen.

Zu speichern sind 302, exakter Contact, dekodierter Body, Entscheidung von A, A–T-Transaktion und T–B-Transaktion. Eine Umleitung ist eine vorgeschlagene Handlung.

Zwei erfolgreiche Medienbeine bewiesen keine Zugänglichkeit

Der Zweck des Modells umfasst Dienste für gehörlose, schwerhörige und sprachbehinderte Menschen. Sprache-zu-Text ist ein Beispiel.

Erfolgreiche Signalisierung und Medien auf beiden Strecken beweisen noch nicht, dass Sprache, Richtung, Genauigkeit, Verzögerung und Darstellung für die Person geeignet waren.

Infrastrukturmetriken enden am Dienst. Zugänglichkeitsnachweise müssen das menschliche Ergebnis beobachten oder ehrlich „unbekannt“ ausweisen.

Wer Paketzustellung zu verstandenem Inhalt hochstuft, verwechselt erneut Beschreibung und Auftrag: SDP kann Medien beschreiben, aber keinen menschlichen Erfolg garantieren.

Die zwei Körperteile verlangten zwei Verantwortlichkeiten

Medienteams können für SDP und Transformationsqualität zuständig sein. Identity- und Security-Teams müssen Listenintegrität, Zielherkunft, Nutzerautorisierung und Darstellung verantworten.

Wenn beides in einem einzigen „Call Setup“-Prozess verschwindet, wird niemand Eigentümer einer manipulierten Zielliste oder eines falsch gebauten SDP.

Lu Hengs Minimum Initial Specification dient hier als offengelegte Linse. Der Mindestvertrag umfasst Aufrufer, Autorisierung, geschützte Einzel-URI, Datenschutz, zwei Transaktionen, streckenspezifische Antworten und Dienstidentität.

Reality Layers trennt Zielliste, Identität, Transaktion, Status, Medien und menschliches Verstehen. Gemeinsame Verpackung macht sie nicht zur selben Realität.

Der Auftrag war klein, aber nicht trivial

RFC 5370 beschränkt T auf einen bekannten Empfänger und eine neue Anfrage. Gerade diese Enge macht seine Sicherheitsentscheidung nachvollziehbar.

Die technische Versuchung besteht darin, den Dienst später „hilfreicher“ zu machen: Gruppen auflösen, Ausweichziele wählen, Identität vereinheitlichen. Jede Erweiterung kann nützlich sein und zugleich den ursprünglichen Autoritätsvertrag verlassen.

Deshalb muss die Implementierung nicht nur erfolgreiche Umwandlung messen. Sie muss beweisen, dass die Liste weiterhin genau den Auftrag enthält, für den die Ausnahme und die Transaktionskorrelation entworfen wurden.

SDP sagte, welche Medien T bearbeiten sollte. Die Liste sagte, gegenüber wem T handeln durfte. Keine der beiden Aussagen ersetzte die andere.