Zusammenfassung

  • Nach RFC 3087 konnte ein SIP-Client oder Proxy durch eine besondere Request-URI festlegen, ob eine Anwendung eine Nachricht annimmt, eine bestimmte Ansage spielt, Nachrichten abruft oder zunächst eine PIN verlangt.
  • Die URI wählte lokal provisioniertes Verhalten. Sie belegte weder die Identität des Anrufers noch dessen Mailbox-Recht, den tatsächlichen Umleitungsgrund oder das Speichern und Anhören einer Nachricht.

Das logische Ziel blieb, der aktuelle Dienst wechselte

Klassische Mailboxen konnten angerufene Nummer, Rufnummer des Anrufers und Umleitungsgrund auswerten. Daraus folgte die Besetztansage, eine Ansage nach Nichtmelden oder der direkte Einstieg in die eigene Abfrage. Der Komfort setzte voraus, dass die Signale der Telefonanlage ihre vertraute lokale Bedeutung behielten.

SIP ließ beweglichere Wege zu. Eine Anfrage konnte von mehreren Proxies auf neue Ziele gelenkt werden. Das Feld To durfte weiter die ursprünglich angerufene Person nennen, obwohl nun ein anderer Dienst zuständig war. RFC 3087 zeigt das mit einer kurzen Kette: A ruft B, B leitet alles an C weiter, C leitet an die eigene Mailbox. Wer To: B als Mailboxschlüssel verwendet, öffnet den falschen Bestand.

RFC 3087 erschien im April 2001 als Informational und führte weder Methode noch Header ein. Es nutzte eine vorhandene Eigenschaft aus RFC 2543: Anders als To durfte ein Proxy die Request-URI auf das aktuelle Benutzer- oder Dienstziel umschreiben. Wenn dieses Ziel eine Dienstidentität war, konnte es zugleich den Startzustand der Anwendung auswählen.

Die Neuerung lag weniger in der Syntax als in der Zuständigkeit. Der Zieldienst musste Kontext nicht aus brüchigen Spuren erraten; die Routingentscheidung lieferte ihn ausdrücklich.

Ein Dienst konnte viele Eingänge haben

Das Dokument beschreibt mehrere SIP-Identitäten für einen Teilnehmer. Eine nimmt Nachrichten mit normaler Ansage an, eine mit Besetztansage, eine mit besonderer Ansage. Für den Abruf kann ein Eingang eine vorherige SIP-Authentifizierung erwarten, ein anderer eine PIN über die Sprachverbindung abfragen. Allgemeine Eingänge ermitteln zunächst die gewünschte Mailbox.

Ein Find-me-Proxy konnte den Eingang bestimmen. Blieben alle Kontakte ohne Antwort, wählte er die normale Ablage. Meldeten alle besetzt, nahm er die Besetztansage. Ein Nicht-stören-Zustand führte zu einem weiteren Ziel. Die Mailbox erhielt die ausgewählte aktuelle Adresse und musste die Entscheidung nicht aus To, From und Telefonnetz-Gewohnheiten rekonstruieren.

Lesbare URI-Namen waren jedoch keine standardisierte Befehlssprache. RFC 3087 warnte davor, mnemonischen Zeichenketten feste Semantik aufzuzwingen. Der Betreiber konnte deposit, eine Ziffernfolge, einen Parameter oder eine andere gültige SIP-URI provisionieren. Erst seine Konfiguration verband Identität und Verhalten.

Darum beweist busy in einem Mitschnitt kein Besetztzeichen. Der Mitschnitt belegt nur, dass diese Zeichenfolge an einem beobachteten Hop das Ziel war. Bedeutung und Auswahlgrund benötigen zusätzlich die damals aktive Zuordnung und das Protokoll der Proxyentscheidung.

Der richtige Eingang war noch kein Schlüssel

Die Abrufszenarien trennen Dienstwahl und Zulassung. Eine vertrauenswürdige Quelle konnte Authentifizierung über eine gesicherte Beziehung delegieren. Erfolgreiche SIP-Authentifizierung konnte den vorgesehenen Ablauf freigeben. Scheiterte sie oder fehlte sie, durfte der Dienst zum Eingang mit PIN-Abfrage umleiten.

Eine teilnehmerspezifische Abruf-URI wählte also einen Ablauf, erteilte aber keine Leseberechtigung. Vertrauensbeziehung, SIP-Zugangsdaten oder PIN öffneten die nächste Schranke. Auch eine erkannte PSTN-Rufnummer blieb eine vom Anbieter akzeptierte Annahme und war kein kryptografischer Nachweis des sprechenden Menschen.

Alle ausführlichen Abläufe setzen einen schützenden Proxy und Vertrauen zwischen Proxy und Mailbox voraus. Der Sicherheitsabschnitt fügte keinen eigenen Schutz hinzu, sondern verwies auf SIP.

Ein Netzprotokoll trägt daher nur eine begrenzte Beweiskette: Ein INVITE traf ein, der Proxy wählte eine Request-URI, die Anwendung nahm das Ziel an, ein Authentifizierungszweig lief, RTP wurde aufgebaut. Kein Einzelschritt beweist Eigentum an der Mailbox, Wahrheit des früheren Umleitungsgrunds, dauerhafte Speicherung oder späteres Anhören.

Lokale Zuordnung war noch keine gemeinsame Sprache

RFC 3261 ersetzte die frühe SIP-Spezifikation, behielt aber den Mechanismus: Die Request-URI bezeichnet den aktuell adressierten Benutzer oder Dienst, und ein Proxy ersetzt sie bei der Zielwahl. Spätere History-Info-Spezifikationen konnten Umleitungsverläufe transportieren. Sie erklären die Ebenen, belegen aber keine konkrete RFC-3087-Installation.

RFC 4458 definierte 2006 die URI-Parameter target und cause für Mailbox- und Sprachdialoganwendungen. Seine Begründung markiert die Grenze: Jeder Hersteller konnte lokale Zuordnungen konfigurierbar machen, doch damit verstanden Rufsteuerung, Gateways und Unified-Messaging-Systeme verschiedener Hersteller Mailbox und Ursache noch nicht gleich.

RFC 3087 zeigte die URI als Kontrollfläche innerhalb einer Architektur. RFC 4458 gab Implementierungen gemeinsame Namen für zwei Informationen. Dass der zweite Schritt nötig war, beweist weder Verbreitung noch Scheitern des ersten.

Beständig bleibt die Trennung der Nachweise. Ursprüngliches Ziel, aktuelle Request-URI, Umschreibungsgrund, lokale Zuordnung, Authentifizierung, Menü, Medienverbindung und Speicherbeleg hängen zusammen, sind aber nicht derselbe Sachverhalt. Kontext im Routing verringert Raten. Routing wird dadurch nicht zur Identität.

Quellen

  1. https://www.rfc-editor.org/info/rfc3087
  2. https://www.rfc-editor.org/rfc/rfc3087.html
  3. https://www.rfc-editor.org/rfc/rfc3087.txt
  4. https://datatracker.ietf.org/doc/rfc3087/
  5. https://www.rfc-editor.org/errata/rfc3087
  6. https://www.rfc-editor.org/rfc/rfc2543.html
  7. https://www.rfc-editor.org/rfc/rfc3261.html
  8. https://www.rfc-editor.org/rfc/rfc4244.html
  9. https://www.rfc-editor.org/rfc/rfc4458.html
  10. https://www.rfc-editor.org/rfc/rfc3326.html
  11. https://www.rfc-editor.org/rfc/rfc5411.html
  12. https://www.rfc-editor.org/rfc/rfc7044.html