Zusammenfassung

  • Der Proxy muss regelmäßig neue PURR-Werte erzeugen, selbst wenn die Push-Parameter unverändert bleiben. Alte Werte muss er erhalten, solange die zugehörigen Dialoge laufen.
  • PURR ist innerhalb des Proxykontexts eindeutig, aber keine weltweite Geräteidentität. Dialogentscheidung, Route, Registrierung und Befugnisse des Push-Dienstes bleiben getrennte Voraussetzungen.
  • Datenschutz verlangt weniger externe Verknüpfbarkeit, nicht das sofortige Vergessen jeder internen Abhängigkeit. Die begrenzte lokale Zuständigkeit muss einen Kennungswechsel überstehen.

Ein Wechsel entlässt niemanden aus der Restpflicht

Bei einer Wartung kann alles Neue funktionieren. Der Proxy nimmt eine Registrierung an, gibt eine frische Referenz aus und unterstützt den nächsten Dialog. Trotzdem ist eine wesentliche Frage offen: Kann er einen bereits laufenden Dialog bedienen, der noch einen früheren Wert verwendet?

Zur Erklärung nennen wir die frühere Referenz P1 und eine später ausgegebene P2. Das sind erfundene Bezeichnungen, keine Paketmitschnitte oder sendefertigen Protokollbeispiele. Ein Dialog beginnt mit P1; eine spätere Registrierung liefert P2. Ein weiterer Dialog kann P2 bekanntgeben, während eine Anfrage innerhalb des ersten noch P1 enthält.

Wurde die Zuordnung zu P1 gelöscht, hilft die erfolgreiche Auflösung von P2 nicht. Die neue Funktion ist nachgewiesen, die fortbestehende Abhängigkeit nicht. Der Fehler liegt in der Annahme, Ausgabe und Ablösung seien derselbe Vorgang: Weil es einen neuen Wert gibt, soll der alte keine Aufgabe mehr haben.

RFC8599, veröffentlicht im Mai2019, trennt diese Vorgänge ausdrücklich. Abschnitt6.2.1 verlangt die regelmäßige Erzeugung einer neuen Proxy Unique Registration Reference, kurz PURR, auch bei unveränderten Push-Parametern. Zugleich sind alte Werte aufzubewahren, solange ihre zugehörigen Dialoge andauern. Das eine Gebot ist keine Ausnahme vom anderen.

Damit wird nicht jede historische Information zum ewigen Bestand erklärt. Erhalten werden muss die Referenz wegen einer konkreten laufenden Abhängigkeit. Nach außen weniger stabile Werte anzubieten und intern die notwendige Zuordnung weiterzuführen, sind unterschiedliche Aufgaben. Ein gutes Zustandsmodell kann beide abbilden, statt Datenschutz gegen Gesprächskontinuität auszuspielen.

Registrierung und Empfangsbereitschaft sind verschieden

Ein mobiles Betriebssystem kann die Anwendung anhalten. Eine SIP-Registrierungsbindung kann noch gültig sein, obwohl die Anwendung nicht kontinuierlich Signalisierung empfangen kann. Die Push-Funktion soll diese Verfügbarkeitsbedingung wiederherstellen: Der Proxy fordert eine Benachrichtigung an, der User Agent wacht auf und erneuert seine Registrierung.

Die Benachrichtigung ist nicht die SIP-Anfrage selbst. Ihre Annahme beim Dienst beweist weder den Empfang der Anfrage noch eine abgeschlossene Registrierung. Ebenso wenig hält sie die Transaktion beim ursprünglichen Absender unbegrenzt offen. Aufwecken und zustellen müssen auseinandergehalten werden.

Der User Agent erhält von seinem Push Notification Service, PNS, eine Push Resource ID, PRID. Deren Format hängt vom Dienst ab. Bei der SIP-Registrierung übermittelt er dem Proxy den Anbieter, die PRID und gegebenenfalls einen weiteren anbieterspezifischen Parameter. Mit diesen Angaben kann der Proxy eine Benachrichtigung anfordern.

Entdeckung, Registrierung und Pflege der Beziehung zum konkreten PNS liegen außerhalb des von RFC8599 beschriebenen Verfahrens. Es gibt hier kein gemeinsames globales Konto und keine einheitliche Lebensdauer aller Anbieterressourcen. Eine gültige SIP-Registrierung lässt deshalb nicht automatisch auf fortbestehende Befugnisse beim Anbieter schließen.

Transportverbindung, Registrierungsbindung, Push-Ressource, Dialog und einzelne Transaktion haben verschiedene Endbedingungen. Dass ein Dialog läuft, macht eine gelöschte Bindung nicht wieder gültig. Dass eine neue Registrierung gelingt, beendet nicht sämtliche früheren Dialoge. Eine einzige Anzeige „Gerät aktiv“ wäre für diese Entscheidung zu grob.

Die Verfahren gelten außerdem für einzelne Bindungen. Ein User Agent kann mehrere besitzen; nach dem Aufwecken werden seine Registrierungen nach den vorgesehenen Regeln erneuert. Eine erfundene weltweite Gerätebindung würde diese Granularität verdecken, statt die Zuständigkeiten zu klären.

Eine lokale Referenz statt privater Anbieterangaben

Der Gesprächspartner muss nicht alle Angaben kennen, die der Proxy für Push benötigt. RFC8599 verbietet dem User Agent, die betreffenden Push-URI-Parameter in Nicht-REGISTER-Anfragen einzufügen, mit der ausdrücklichen Ausnahme von pn-purr. pn-provider, pn-prid und pn-param sollen dem entfernten Teilnehmer gerade nicht als normale Dialoginformation zugänglich werden.

PURR stellt eine Indirektion bereit. Der Proxy erzeugt den Wert und sucht damit die gespeicherten Informationen zum Anfordern einer Benachrichtigung. Die geforderte Eindeutigkeit gilt innerhalb seines Kontexts. Sie fordert weder eine zentrale Vergabestelle noch eine dauerhafte Nummer, unter der alle Netze dieselbe Anwendung erkennen.

Der Wert muss unfälschbar, anonym und für andere Entitäten als den Proxy nicht verknüpfbar sein. Ein ausreichend großer Raum sicher erzeugter Zufallswerte ist eine mögliche Umsetzung. Der Standard schreibt damit nicht allen Betreibern denselben Algorithmus, dieselbe Datenbank oder dieselbe Speicherorganisation vor.

Dass der verantwortliche Proxy die Beziehung herstellen kann, ist notwendig. Sonst könnte er die private Funktion nicht ausführen. Die Grenze betrifft die Verknüpfbarkeit durch Außenstehende. Weniger offengelegte Information kann mit einer engen, intern erhaltenen Zuordnung zusammengehen.

Diese Eigenschaften garantieren keine vollständige Anonymität der SIP-Kommunikation. Andere Header, Dialogverhalten oder Betriebsprotokolle können weitere Informationen enthalten. Eine undurchsichtige Referenz beweist weder anonyme Logdateien noch die Abwesenheit jeder anderen Identifikationsmöglichkeit. Zusagen müssen auf den tatsächlich geschützten Gegenstand begrenzt bleiben.

Auch GRUU ist etwas anderes. RFC5627 beschreibt eine global routbare URI zu einer bestimmten User-Agent-Instanz. PURR dient hier der lokalen Suche nach Registrierungsinformationen für Push. Beide können Erreichbarkeit unterstützen, haben aber nicht denselben Identitäts- oder Routingumfang.

Eine regelmäßig wechselnde Außenreferenz erschwert die Zuordnung über einen unveränderten Wert. Eine intern bewahrte alte Zuordnung hält dagegen einen laufenden Dienst nutzbar. Aus ihrer notwendigen Speicherung folgt nicht, dass sie öffentlich oder proxyübergreifend als Aktivitätsindex angeboten werden sollte.

Jeder Dialog hat eine eigene Entscheidung

Der Proxy kann die Funktion unterstützen, ohne dass jeder Dialog sie verwendet. RFC8599 legt die Wahl in die lokale Policy des User Agents. Dieser entscheidet, ob eingehende Anfragen während des betreffenden Dialogs Push-Unterstützung nutzen sollen; Eigenschaften des Dialogs oder seiner Medien können dabei berücksichtigt werden.

Bei Teilnahme fügt der User Agent pn-purr in den einschlägigen initialen Contact ein und verwendet den zuletzt erhaltenen Wert von sip.pnspurr. Fehlt der entsprechende Indikator, darf er den Parameter nicht selbst erfinden. Der andere Teilnehmer erhält eine tatsächlich angebotene Referenz, keine Behauptung über die Fähigkeiten eines unbekannten Vermittlers.

RFC6809 definiert den Feature-Caps-Rahmen für Fähigkeiten von Entitäten, die nicht durch die Contact-URI repräsentiert sind. Der IANA-Eintrag zu sip.pnspurr beschreibt die Zuordnung von Anfragen im Dialog zu Registrierungsinformationen. Er erklärt nicht den Gesprächspartner zum allgemeinen Berechtigten beim Push-Anbieter.

Die Dialogwahl, die passende Route, eine auflösbare Zuordnung, die gültige Registrierung und die Annahme durch den Anbieter sind verschiedene Bedingungen. Eine erkannte Referenz ersetzt keine von ihnen. Ein erfolgreich angenommener Push-Auftrag beweist auch nicht nachträglich, dass die Dialogentscheidung korrekt war.

So bleibt Anwendungswissen bei der Anwendung. Es ist keine zentrale Stelle nötig, die jeden Dialog klassifiziert oder erlaubt. Der Betreiber bleibt dennoch für seine Bedingungen zuständig: Er kann Routing- oder Registrierungsfehler nicht mit einer erfolgreichen Anbieterantwort wegargumentieren.

Die Aufbewahrung folgt der Abhängigkeit

Eine spätere Registrierungsantwort kann den neuen Wert liefern, ohne damit die frühere Kontaktinformation aller laufenden Dialoge zu ersetzen. Falls ein Dialog weiter P1 benutzt, besitzt P1 noch eine Aufgabe. Die Ausgabe von P2 enthält keine universelle Erklärung über das Ende dieser Aufgabe.

Das begrenzt die Aussagekraft eines Bereinigungsplans. RFC8599 knüpft das Behalten alter Werte an zugehörige laufende Dialoge. Es nennt weder einen weltweiten Wechselrhythmus noch eine feste Stundenzahl, nach der jede alte Referenz entfallen darf. Ein lokaler Termin kann eine Abhängigkeit nicht allein durch sein Verstreichen schließen.

Umgekehrt ist keine ewige Sammlung verlangt. Die fortbestehende Beziehung liefert den Grund und die Grenze der Aufbewahrung. Die relevante Frage lautet, welche laufenden Dialoge noch darauf angewiesen sind und wie diese Abhängigkeit endet. Sofortiges Löschen und endloses Speichern sind keine erschöpfenden Alternativen.

Für Kapazitätsplanung kann deshalb mehr als die Zahl aktueller Registrierungen wichtig sein. Ausgaberhythmus, Dialogdauer und das Auflösen beendeter Abhängigkeiten können eine Rolle spielen. Das ist eine betriebliche Folgerung, keine hier gemessene Größe und kein vorgeschriebenes Datenmodell.

Ein Proxywechsel ist ein besonders aussagekräftiger Fall. Die jüngste Registrierung kann auf dem Nachfolger vorhanden sein, während frühere Referenzen dort nicht auflösbar sind. Speicherung, Aufteilung und Übergabe müssen also die noch genutzten Zuordnungen berücksichtigen.

RFC8599 definiert kein allgemeines Replikations- oder Migrationsprotokoll und keine universelle Schlüsselwechselprozedur. Der lokale Betreiber muss seine Kontinuität selbst erklären. Die Teilnahme am Mechanismus ist kein Beleg dafür, dass jede Wartung dieses Betreibers die Zuständigkeit korrekt übergibt.

Ein weltweites PURR-Verzeichnis ist daraus nicht zwingend abzuleiten. Es könnte Übergaben erleichtern und zugleich Kenntnisse über mehrere Proxykontexte zusammenführen. Bequemlichkeit ist ein möglicher Nutzen, aber kein Beweis dafür, dass die ursprünglich lokale Referenz einen globalen Index benötigt.

Die Anfrage muss den zuständigen Proxy erreichen

Eine erhaltene Zuordnung ist nutzlos, wenn die Anfrage ihren Besitzer umgeht. Im einschlägigen initialen Dialogverfahren trägt sich der unterstützende Proxy in Record-Route ein, damit weitere Dialoganfragen über ihn laufen. RFC3261 liefert den Rahmen aus Dialogrouten und entferntem Ziel.

Das ist nicht dasselbe wie Path. RFC3327 hält Vermittler fest, die für das Erreichen eines registrierten User Agents relevant sind. Record-Route betrifft den Weg innerhalb eines etablierten Dialogs. Eine richtige Registrierungsroute beweist nicht allein den späteren Besuch beim PURR-haltenden Proxy.

RFC5626 behandelt vom User Agent aufgebaute Verbindungen, Keep-alives und mehrere Flows unter anderem bei NAT- und Firewallbeschränkungen. Das sind wiederum andere Erreichbarkeitsbedingungen. Eine passende Verbindung garantiert nicht, dass die mobile Anwendung ohne Aufwecken empfangsbereit ist.

Bei der betreffenden Anfrage im Dialog steht pn-purr abhängig vom Routensatz in der Request-URI oder einer Route-URI. Kann der Proxy die Informationen wiederfinden, hält er die SIP-Anfrage im Push Bucket zurück und fordert eine Benachrichtigung an. Die2xx-Antwort der zugeordneten REGISTER-Transaktion führt zur Weiterleitung der entsprechenden Anfrage.

Dabei findet nicht der URI-Vergleich aus Abschnitt5.3 statt. Eine Anfrage im Dialog enthält gerade nicht pn-prid, pn-provider und pn-param. Der Proxy verwendet die PURR-Zuordnung zur Registrierungsantwort. Die private Indirektion verändert somit die Assoziation im Verfahren, nicht bloß die sichtbare Verpackung.

Diese Beschreibung gilt für Abschnitt6.2.3. Initiale Anfragen besitzen andere Bedingungen, einschließlich transportabhängiger Reihenfolgen. Es wäre falsch, daraus eine immer geltende Wartepflicht auf REGISTER2xx für sämtliche SIP-Anfragen abzuleiten.

Fortbestehende Pflicht ist keine ewige Befugnis

Wird der Proxy über Ablauf oder Entfernung einer Registrierungsbindung informiert, darf er mit der betreffenden PRID keine weiteren Push-Benachrichtigungen anfordern. Dass eine alte PURR noch im Dialog vorkommt, hebt diese Grenze nicht auf. Sie belebt weder eine gelöschte Bindung noch eine ungültige Anbieterressource.

Auch die wartende Transaktion endet. Während der Proxy auf Benachrichtigung und Registrierung wartet, kann der Absender die Anfrage wegen Zeitüberschreitung als gescheitert betrachten. RFC8599 benennt diese Grenze und empfiehlt einen Fehler, der hauptsächlich die betroffene Transaktion trifft, statt unnötig den gesamten Dialog zu beschädigen.

Aufbewahrung verspricht daher nicht ständige Verfügbarkeit oder zwangsläufig erfolgreiche Zustellung. Sie ist eine begrenzte Verantwortung innerhalb tatsächlich bestehender Bedingungen. Eine zu späte Reaktion kann ihre ursprüngliche Wirkung verlieren, obwohl Anwendung und Registrierung inzwischen wieder funktionieren.

Authentisierung und Autorisierung des jeweiligen PNS liegen in dessen eigener Spezifikation. RFC8599 verlangt außerdem geeigneten Schutz der SIP-Signalisierung und das Eindämmen privater Push-Parameter. Auch Benachrichtigungen über Registrierungsereignisse dürfen diese Angaben nicht unbedacht an andere Nutzer oder nicht vertrauenswürdige Entitäten weitergeben.

RFC8030 erläutert HTTP-Web-Push-Sicherheit, entscheidet aber nicht die Dialogpolicy der SIP-Anwendung. Anbieterannahme, Referenzauflösung und bestehender Dialog sind verschiedene Tatsachen. Ihre Zusammenfassung als allgemeines Recht zum Aufwecken erschwert es, unnötige Unterbrechungen, Batteriebelastung und Signalisierungsverkehr einer Zuständigkeit zuzuordnen.

Beide Grenzen müssen gelten: Neue Ausgabe beendet keine fortbestehende Abhängigkeit; eine alte Abhängigkeit verlängert keine erloschene Befugnis. Das trennt Speicherung und Verwendung, statt beides über einen groben Aktivschalter zu regeln.

Dokumentation liefert keine Betriebsbestätigung

Das versionsgebundene OpenSIPS3.6-registrar-Handbuch beschreibt pn_enable_purr, pn_process_purr und das konfigurierbare pn_refresh_timeout. Es zeigt konkrete Flächen für Fähigkeitsanzeige, Suche und Warten. Es ist keine Prüfung eines gegenwärtig betriebenen Clusters.

Die beiden OpenSIPS-Beiträge von2020 erklären Registrierung und Anfragen im Dialog als historische Implementierungsquellen. Sie beweisen nicht die korrekte Erhaltung und Übergabe sämtlicher alter Zuordnungen in einer konkreten Installation. Für diese Untersuchung wurde kein SIP-Betreiber getestet.

Auch Errata behalten ihren Status. Das verifizierte redaktionelle Erratum8136 korrigiert sip.pnsreq zu sip.pnsreg in Abschnitt4.1.4. Das gemeldete technische Erratum7136 betrifft REGISTER-Request-URI-Beispiele und ist keine angenommene normative Änderung.

Die Regel, ihre dokumentierte Umsetzung und ihr Nachweis im Betrieb sind unterschiedliche Evidenzstufen. Namen von Parametern überbrücken die letzte Stufe nicht. Diese Grenze offen zu nennen, ist für Entscheidungen nützlicher als eine nicht durchgeführte Prüfung durch Erwartungen zu ersetzen.

Die Schlussfolgerung bleibt dennoch eindeutig: Außenreferenzen sollen wechseln, während notwendige alte Zuordnungen lokal erhalten bleiben. Ein neuer Wert verändert, was kommende Dialoge sehen. Er erklärt nicht die bisherige Verantwortung für einen laufenden Dialog für beendet.

Quellen