Zusammenfassung

  • RFC 3136 beschrieb eine SPIRITS-Architektur, in der ein Ereignis aus dem Telefonnetz einen Internetnutzer benachrichtigen und dessen gewählte Anrufbehandlung zurück zur Telefonsteuerung tragen konnte.
  • Der Klick war nicht die Behandlung. Gateway und SPIRITS Client mussten die Auswahl übertragen, die SCF sie in Telefonaktionen übersetzen und der Switch die angehaltene Verarbeitung fortsetzen.

Die Oberfläche entschied schneller als die Vermittlung

Bei einer Einwahlverbindung teilten sich Modem und Sprachtelefon dieselbe Leitung. Kam während der Internetsitzung ein Anruf an, besaß das Telefonnetz den Anrufzustand; der PC besaß die Datensitzung. Internet Call Waiting sollte beide Seiten für eine kurze Entscheidung verbinden.

Ein Fenster konnte Nummer oder Namen anzeigen und Optionen anbieten: Internet trennen und annehmen, an eine andere Nummer weiterleiten, zur Mailbox schicken, eine Nachricht abspielen oder ablehnen. Die Anwendung konnte zweifelsfrei feststellen, was der Teilnehmer auswählte.

Sie konnte daraus nicht allein erkennen, was der Anrufer erlebte. Der Call lag in einer Telefonvermittlungslogik, möglicherweise angehalten und mit einer Frist. Zwischen Mausklick und Leitung lagen mehrere Beobachter und Entscheider.

RFC 3136 erschien im Juni 2001 als Informational RFC. The SPIRITS Architecture war keine vollständige Protokollspezifikation. Das Dokument benannte Komponenten und logische Schnittstellen für Dienste, die im PSTN begannen und Internetfunktionen benötigten. Eine Verbindung im Diagramm bewies daher weder eine konkrete Implementierung noch Interoperabilität oder Ergebnis.

Der erste Zustand gehörte dem Telefonnetz

Die Service Switching Function, meist im Switch, erkannte Intelligent-Network-Trigger und interagierte mit der Service Control Function. Die SCF führte Dienstlogik aus und konnte die Vermittlung beeinflussen.

Schon dieser Anfang bestand aus mehreren Belegen: Der Anruf erreichte einen Detection Point. Der SSF erkannte den Trigger. Die Information gelangte zur SCF. Die Steuerung erzeugte ein Ereignis für die Internetseite. Ein erfolgreicher Schritt machte den nächsten nicht automatisch wahr.

Der SPIRITS Client saß auf der Telefonseite. Er nahm PSTN-Anfragen der SCF entgegen und sandte Antworten zurück. Er durfte mit der SCF zusammenlaufen oder über Schnittstelle D getrennt sein. Logische Kästen beschrieben Verantwortung, nicht zwingend getrennte Hardware.

Ein SPIRITS Gateway vermittelte zum IP-Bereich und konnte mit PINT-Komponenten koexistieren. Der SPIRITS Server beendete PSTN-Anfragen und führte die Interaktion mit dem Teilnehmer: Benachrichtigung hinein, gewählte Behandlung hinaus. „Server“ bedeutete nicht Herrschaft über den Switch.

Fünf Schnittstellen, fünf begrenzte Aussagen

A transportierte PINT-Anfragen vom Host zum PINT Server. In SPIRITS diente sie vor allem der Sitzungsregistrierung und Aktivierung, möglicherweise auch der Subscription. Eine aktive Sitzung belegte weder einen späteren Trigger noch Erreichbarkeit des Hosts.

B verband SPIRITS Server und Gateway. Zum Nutzer liefen Benachrichtigung und verfügbare Anruferdaten; zurück lief die aktuelle Disposition. Der Hinweg konnte funktionieren, während der Rückweg scheiterte. Gateway-Empfang war noch kein SCF-Empfang.

C verband Gateway und SPIRITS Client. Das Gateway konnte mit dem Server kommunizieren oder als virtueller Server Anfragen selbst terminieren. Ein „terminated“-Eintrag war deshalb ohne Implementierungskontext weder Fehler noch Beweis eines weiteren Hops.

D verband Client und SCF. Triggerparameter gingen zum Client, die Teilnehmerdisposition zurück. RFC 3136 sagte ausdrücklich, die SCF „transformiere“ die Nutzerauswahl in passende Aktionen—etwa eine Ansage—und nehme die angehaltene Call-Verarbeitung im SSP wieder auf.

E brachte PINT-Anfragen zur Ausführung an die SCF. PINT begann mit einer Internetanfrage an das Telefonnetz; SPIRITS mit einem Telefonereignis an Internetdienste. Gemeinsame Bausteine ließen die Richtungen nicht verschmelzen.

„Ablehnen“ musste erst Telefonzustand werden

Wählt der Nutzer Ablehnen, kann der PC Identität, Sitzung, Zeitpunkt und Schaltfläche speichern. Der Server kann codieren, das Gateway prüfen und der Client an die SCF liefern. Bis dahin existiert ein authentischer Wunsch am Entscheidungspunkt.

Die SCF muss ihn anhand von Dienstvertrag, aktuellem Call State und Betreiberregeln interpretieren. Eine Ablehnung kann Ansage und Freigabe erfordern. Der SSP muss rechtzeitig handeln. Kommt die Nachricht nach dem Timeout, kann sie korrekt und dennoch wirkungslos sein.

Weiterleitung verlängert die Kette. Eine gültige Zielnummer und eine akzeptierte Vermittlungsanweisung sagen nicht, ob das Ziel frei ist oder abnimmt. Eine Mailbox kann antworten, ohne eine brauchbare Nachricht zu speichern. Annahme kann erst nach Ende der Modemsitzung möglich sein. VoIP-Annahme wurde erwähnt, aber von der vorgeschlagenen Architektur ausdrücklich nicht abgebildet.

Eine vollständige Beweiskette trennt daher Registrierung, Trigger, Benachrichtigungserzeugung, Zustellung und Anzeige, manuelle oder profilbasierte Auswahl, Server/Gateway/Client-Empfang, SCF-Transformation, Switch-Ausführung, Zielergebnis und unabhängigen Readback.

Auch die automatische Regel brauchte Ausführung

Teilnehmer konnten Standardregeln oder nummernspezifische Dispositionen hinterlegen. Dann wurde kein Live-Fenster benötigt; später zeigte ein Log Datum, Zeit, Rufnummer, Namen und Behandlung.

Das Protokoll war ein lokaler Beobachter. „Forwarded“ konnte Regelwahl, gesendete Anweisung oder eine lokale Erfolgsklassifikation bedeuten. Ohne Messpunkt und Abschlusskriterium bewies es kein Klingeln und keine menschliche Annahme.

RFC 2995 untersuchte zuvor vier Pre-SPIRITS-Implementierungen. Alle unterstützten Internet Call Waiting, die meisten verwendeten SIP, und alle nutzten IN-Lösungen auf der PSTN-Seite. Der Bericht sagte zugleich, dass nicht alle interoperierten und selbst SIP-Systeme nicht zwingend dieselbe Version unterstützten.

Auch „SPIRITS server“ hatte je nach Implementierung eine andere Bedeutung. Running Code belegte reale Systeme und reale Vielfalt, nicht eine universelle Semantik aller Erfolgsfelder.

Benachrichtigung vergab keine Call-Autorität

RFC 3298 verlangte später, dass das minimale SPIRITS-Protokoll einfache Benachrichtigung ohne PINT und ohne persistente PSTN-Interaktion leisten konnte. Ein Host konnte also über ein Ereignis informiert werden, ohne den Anruf beeinflussen zu dürfen.

Für Disposition zeichnete RFC 3298 die Abfolge Registrierung, Event Notification, Call Disposition, Service Control und SSP. Die Reaktion auf die Meldung war ein weiterer notwendiger Teil der Diensterbringung. Accept, Reject und Redirect gehörten zum Vokabular; VoIP-Annahme blieb außerhalb des Scopes.

Eine ehrliche UI unterscheidet Ereignis empfangen, Auswahl gesendet, Policy akzeptiert, Switch ausgeführt und Ziel erreicht. Ein einziges Häkchen würde Rechte und Beobachtungspunkte vermischen.

RFC 3910 spezifizierte 2004 SPIRITS mit SIP SUBSCRIBE/NOTIFY und XML. Die Internetseite hieß nun Event Subscriber, die PSTN-Seite Notifier. Wer Beobachtung bestellte und wer sie ausstellte, war semantisch wichtiger als Client oder Server.

Das Protokoll trennte Request- und Notification-Detection-Points. Request hielt die SSP-Verarbeitung bis zur SCP-Antwort an. Notification ließ sie nach dem Bericht weiterlaufen. Ein NOTIFY bewies daher nicht, dass die Vermittlung auf Internetentscheidung wartete.

Auch Subscription Acceptance hatte Phasen. Nach 202 meldete ein NOTIFY Annahme und laufende Bearbeitung; ein weiterer folgte nach Initialisierung der Detection Points. Erst ein späteres Ereignis erzeugte die Ereignismeldung. Akzeptiert, vorbereitet und ausgelöst blieben getrennt.

Der entscheidende Übergang blieb lokal

RFC 3910 konzentrierte sich auf B und C und bezeichnete D als lokale Policy des PSTN-Betreibers. D konnte funktionale Schnittstelle oder Nachrichtenaustausch sein. Das gemeinsame Protokoll endete vor dem Punkt, an dem Internetabsicht in SCF-Aktion verwandelt wurde.

Das bewahrte Zuständigkeit. Gemeinsame Ereignisnamen, Pflichtparameter und XML halfen beim Austausch. Der Betreiber entschied weiterhin über Identitäts-Leitungs-Zuordnung, Subscription, verfügbare Behandlung und Mapping in lokalen Call State. Wohlgeformte Syntax war kein universelles Mandat.

Eine minimale gemeinsame Schicht ließ Implementierungen ihre zukünftige Steuerung wählen. Unterschiedliche Ausführung war kein versteckter Fehler, sondern Teil der offen gelassenen lokalen Fläche.

Der Angriffsweg verlief mit der Entscheidung

RFC 3136 sah B über dem öffentlichen Internet als besonders anfällig für Diebstahl und Denial of Service. C konnte im Provider-Intranet liegen; das internetverbundene Gateway öffnete dennoch eine Grenze, an der eine Firewall allein unzureichend sein konnte.

Betrügerische Registrierung konnte Caller-ID-Daten umleiten. Manipulation konnte Mailbox in Weiterleitung verwandeln. Replay konnte eine alte Auswahl auf einen neuen Call anwenden. Selbst eine echte Identität konnte ihre Leitungsberechtigung verloren haben.

Authentisierung, Integrität, Frische, Leitungsbindung, Dispositionsrecht, SCF-Policy, Switch-Ausführung und Zielergebnis sind eigene Prüfungen. Der Klick belegt nur den Wunsch.

Die Einwahl verschwand, die Steuerungsdistanz blieb

Moderne Dashboards bieten Traffic-Umschaltung, Credential-Entzug, Migration oder Abbruch. Der Knopf erzeugt Absicht. Gateway prüft, Policy entscheidet, Controller übersetzt, Gerät handelt, ein späterer Beobachter bestätigt.

RFC 3136 war ehrlich, weil es diese Kette nicht „Klick“ nannte. Der Teilnehmer wählte. Das Netz musste die Auswahl noch verwirklichen.