Zusammenfassung

  • RFC 3372 trennte zwei Aufgaben: Ein gekapselter ISUP-Inhalt bewahrte die ältere Signalisierung für geeignete Endpunkte, während übersetzte SIP-Felder den Vermittlern eine Routingentscheidung ermöglichten.
  • Keine Spur war der Beleg für die andere. Unveränderte Bytes bewiesen weder die richtige Route noch eine erhaltene Funktion; erfolgreiches SIP-Routing bewies weder korrekte ISUP-Rekonstruktion noch Medien- oder Diensterfolg.

Eine Verbindung, die aus dem Telefonnetz kommt, über ein IP-Netz läuft und wieder in das Telefonnetz eintritt, stellt zwei verschiedene Fragen. Welche Informationen hatte das SS7-Netz tatsächlich geliefert? Und welche sichtbaren Angaben brauchte ein SIP-Proxy, um den nächsten Zielpunkt zu bestimmen?

RFC 3372 wurde im September 2002 als BCP 63 veröffentlicht. Der Text nannte den Rahmen SIP-T, erklärte ihn aber ausdrücklich nicht zu einem neuen Protokoll. SIP-T war eine Sammlung von Verfahren für die Grenze zwischen PSTN und SIP. Seine entscheidende Idee war die parallele Führung zweier Darstellungen eines Anrufs.

Die erste Darstellung bestand aus der gekapselten ISUP-Nachricht. Das Eingangs-Gateway erkannte die ISUP-Variante und legte sie mit den in RFC 3204 registrierten MIME-Typen in den SIP-Nachrichtenkörper. So blieben Parameter erhalten, die keine saubere SIP-Entsprechung besaßen. Ein späteres PSTN-Gateway konnte den Inhalt als Vorlage verwenden.

Die zweite Darstellung war die für SIP sichtbare Anfrage. Proxies treffen Entscheidungen anhand von Request-URI und Headern; sie sollen nicht jede ISUP-Variante auswerten. Das Gateway übersetzte daher ausgewählte Werte wie die angerufene Nummer in routbare SIP-Elemente. RFC 3372 ordnete Kapselung der Dienstetransparenz und Übersetzung der Routbarkeit zu.

Gerade diese Trennung zeigte zwei voneinander unabhängige Fehler. Ein vollständiger ISUP-Körper konnte mit einem falsch übersetzten Ziel zum ungeeigneten Gateway gelangen. Eine korrekt geroutete Anfrage konnte ohne Körper, mit beschädigtem Inhalt oder mit einer am Ausgang unbekannten Variante ankommen. Die Integrität des Behälters war kein Beleg für seine richtige Verwendung.

Das Ziel-Gateway spielte den Körper nicht lediglich ab. Es durfte ihn als Vorlage nehmen, Werte aus SIP-Headern überschreiben und Parameter gemäß lokaler Richtlinie ergänzen. Fehlte ISUP, konnte eine vorkonfigurierte Standardvorlage einspringen. Die ausgehende PSTN-Nachricht war folglich eine nachvollziehbare Rekonstruktion mit lokalen Entscheidungen.

Auch der Endpunkttyp war beim Start oft offen. Ein PSTN-Anruf konnte an einem SIP-Telefon enden. Dieses Telefon ignorierte ISUP normalerweise, sollte multipart und unbekannte MIME-Inhalte nach RFC 2046 und RFC 3261 aber korrekt tolerieren. Ein SIP-Telefon als Ursprung musste umgekehrt kein ISUP erzeugen, nur weil später vielleicht ein PSTN-Ziel gewählt wurde.

Signalisierung während eines laufenden Gesprächs bildete eine weitere Naht. Manche ISUP-Information änderte weder SIP-Sitzungszustand noch Medienparameter. RFC 3372 verwies für ihren Transport auf die INFO-Methode aus RFC 2976. Eine zugestellte INFO-Nachricht belegte jedoch nicht, dass ihre Semantik verstanden oder ein Leistungsmerkmal ausgeführt wurde.

TRIP aus RFC 3219 und ENUM aus RFC 2916 standen für Routenermittlung und Nummernauflösung bereit, ersetzten aber nicht den bewahrten ISUP-Kontext. S/MIME nach RFC 2633 konnte Inhalte signieren und schützen. Eine gültige Signatur bestätigte dennoch nicht die Übersetzung, die Berechtigung lokaler Regeln, die Medienverbindung oder eine Abrechnung.

RFC 3398 beschrieb später die detaillierte SIP–ISUP-Abbildung. RFC 3326 ließ protokollbezogene Gründe mitführen, ohne Erklärung und Handlung gleichzusetzen. RFC 3331 und RFC 3332 verlagerten verschiedene SS7-Anpassungsfunktionen über SCTP. Diese Nachbarschaft ist keine Dublette: Dort geht es um den Ort von Signalisierungszustand, hier um die zwei Beweisspuren eines Anrufs.

Die Quellen liefern keine belastbare Verbreitungszahl und keinen Nachweis eines konkreten Betriebs. Sie dokumentieren jedoch eine präzise historische Einsicht. Zusammenschaltung war keine verlustfreie Verwandlung einer vollständigen alten Wahrheit in eine neue. Sie bewahrte ein Spezialformat für den fähigen Empfänger und schuf zugleich eine begrenzte, sichtbare Handlungsfläche für das IP-Netz.

Die Essays von Lu Heng verschärfen diese Lesart. Eine minimale gemeinsame Spezifikation lässt örtliche Entscheidungen erkennbar. Getrennte Realitätsebenen verhindern, dass empfangenes SS7, MIME-Körper, übersetzter Header, Proxyroute, Ausgangsrekonstruktion, Medienpfad und Nutzererlebnis zu einem einzigen Erfolg verschmelzen. RFC 3372 machte den Übergang beherrschbar, indem es Erhaltung und Wirkung nicht verwechselte.

Quellen