Zusammenfassung

  • In RFC 6665 beendet Subscription-State: terminated das Abonnement. Der Wert ist keine allgemeine Aussage, die beobachtete Ressource sei beendet oder verschwunden.
  • Die Gründe weisen in unterschiedliche Richtungen: deactivated kann eine Migration anzeigen, timeout erlaubt ein neues Abonnement, invariant bezeichnet einen stabilen Zustand, und nur noresource erklärt den Ressourcenzustand für nicht mehr existent.
  • Eine belastbare Akte trennt Lebenszyklus des Abonnements, Ressourcenkörper, NOTIFY-Transaktion, Auslegung des Ereignispakets und die spätere menschliche oder automatische Handlung.

Die rote Kachel hat zwei Zustandsmaschinen zusammengezogen

Das Wort „terminated“ verleitet zu einem grammatischen Kurzschluss. Steht es neben einem Gerät, Konto, Anruf oder Ziel, scheint es genau dieses Substantiv zu beschreiben. Im Header von RFC 6665 ist das Substantiv jedoch das Abonnement. Ein Subscriber muss das betreffende Abonnement nach Empfang des Werts als beendet betrachten. Diese Aussage ist verbindlich, aber eng begrenzt.

Die beobachtete Ressource besitzt eine andere Zustandsmaschine, deren Bedeutung das jeweilige Ereignispaket liefert. Es legt fest, ob ein Körper vollständigen oder partiellen Zustand trägt, wie ein neutraler Zustand aussieht und was fehlender Inhalt bedeutet. Das allgemeine SIP-Ereignismodell zwingt Präsenz, Nachrichtenanzeige, Anrufzustand und anwendungsspezifische Ressourcen nicht in eine universelle Semantik.

Eine Beobachtungsbeziehung kann ausfallen, während ihr Gegenstand gesund bleibt. Eine Ressource kann verschwinden, während die abschließende Benachrichtigung noch unterwegs ist. Speichert ein System beides als einziges beendet=true, verliert es die Möglichkeit, den Ausfall der Beobachtung von einer Veränderung des Beobachteten zu unterscheiden.

Sieben Gründe eröffnen verschiedene Zukünfte

Die Beendigungsgründe in RFC 6665 haben konkrete Betriebsfolgen. deactivated fordert sofortiges Neuabonnieren; ein Hauptfall ist die Migration zwischen Notifier-Knoten. probation verschiebt den nächsten Versuch. rejected meldet eine geänderte Autorisierungspolitik und rät von einem weiteren Versuch ab. timeout bedeutet, dass vor Ablauf nicht erneuert wurde, erlaubt aber eine sofortige Neuanmeldung. giveup sagt, der Notifier habe nicht rechtzeitig Autorisierung erlangen können.

Besonders deutlich wird die Grenze beim Paar noresource und invariant. Ersteres besagt, dass der beobachtete Ressourcenzustand nicht mehr existiert. Letzteres garantiert, dass sich dieser Zustand auf absehbare Zeit nicht ändern wird. Beide raten von einer erneuten Anmeldung ab, doch der eine Grund beschreibt Abwesenheit, der andere Fortbestand. Eine Spalte „vorbei“ kann diese Gegensätze nicht bewahren.

Ein Grund kann fehlen oder unbekannt sein. Dann darf der Client unter Beachtung von retry-after erneut abonnieren. Die Lücke berechtigt den Beobachter nicht, noresource zu erfinden. Auch ein expires-Parameter neben terminated füllt sie nicht: Laut RFC besitzt er dort keine Semantik und muss ignoriert werden.

Die letzte Benachrichtigung muss keinen letzten Ressourcenwert tragen

Ein Abonnement wird mit einem SUBSCRIBE und Expires: 0 gekündigt. Nach erfolgreicher Abmeldung folgt ein abschließendes NOTIFY, doch RFC 6665 weist ausdrücklich darauf hin, dass diese Anfrage Zustandsinformationen über die Ressource enthalten kann oder auch nicht. Der Subscriber muss beide Formen verarbeiten können.

Fehlt der Körper, ist nur das Ende der Beziehung bekannt, nicht der letzte Wert der Ressource. Ist er vorhanden, bestimmen weiterhin Medientyp, Paketregeln, Voll- oder Teilzustand und Versionsinformation seine Bedeutung. Der Subscription-Header kann einem von einer anderen Spezifikation geregelten Körper keine Bedeutung verleihen.

Auch die 200-Antwort auf NOTIFY hat eine schmale Aussagekraft. Sobald eine Benachrichtigung akzeptabel ist, soll der Subscriber antworten; die Transaktion darf nicht auf einen Benutzer warten. 200 belegt also die akzeptable automatische Verarbeitung durch ein SIP-Element. Sie ist weder Lesebestätigung noch Zustimmung eines Operators noch Nachweis eines abgeschlossenen Folgeprozesses.

Die Bestätigung kann die scheinbare Gesprächsreihenfolge überholen

Das erste NOTIFY bestätigt die Einrichtung eines Abonnements. Eine 2xx-Antwort auf SUBSCRIBE besagt, dass die Anfrage angenommen wurde und sofort ein NOTIFY gesendet wird. Durch Umordnung, Verlust oder Forking kann das NOTIFY dennoch vor Abschluss der SUBSCRIBE-Transaktion eintreffen. Bis dahin ist die Ressource im neutralen Zustand zu behandeln, den das Ereignispaket definiert.

Damit laufen mindestens drei Uhren: Anfragen und Antworten bilden die Transaktionsuhr; Einrichtung, Erneuerung, Ablauf und Ende die Abonnementuhr; Zustandsänderungen des Pakets die Ressourcenuhr. Eine vierte Uhr gehört dem Beobachter, der empfängt, auswertet und anzeigt. Wer alles nur nach Erfassungszeit sortiert und den letzten Eintrag „Wahrheit“ nennt, kann Ursache und Wirkung umkehren.

Eine prüfbare Aufzeichnung speichert lokalen Abonnementschlüssel, Call-ID und Tags, Event-Wert, Ziel, NOTIFY-CSeq, vollständigen State-Header, Grund, Wiederholungsintervall, Empfangszeit, Authentifizierungsergebnis und Antwort. Getrennt davon gehören Körperpräsenz, Medientyp und Digest, Paket- und Parser-Version, Voll- oder Teilzustand sowie der von der Anwendung abgeleitete Wert in die Akte.

Ein Usage kann enden, während der Dialog weiterlebt

RFC 6665 definiert ein Abonnement als Anwendungszustand, der mit einem Dialog verbunden ist. Robert Sparks erklärt in RFC 5057, weshalb diese Verbindung keine Identität bedeutet. Dialog Usages besitzen unabhängige Lebenszyklen, obwohl sie Dialogzustand teilen. Bei einer Weiterleitung können Invite Usage und Subscription Usage im selben Dialog liegen; das Abonnement endet, während die Invite Usage fortbesteht.

Spätere Arbeiten schärften die Steuerfläche. RFC 7621 klärt den Einsatz von GRUUs, damit Anfragen die beabsichtigte User-Agent-Instanz erreichen. RFC 7647 von Sparks und Roach behandelt durch REFER implizit erzeugte Abonnements und problematische Dialogwiederverwendung. Besseres Targeting und sauberere Dialogstruktur verringern die Unsicherheit darüber, welches Usage ein Ereignis erzeugte. Sie erweitern terminated nicht zur Aussage über die Ressource.

Auch das Etikett „Sitzung beendet“ verwischt Grenzen. Abonnement, Dialog, Dialog Usage, Anruf, Notifier-Instanz und paketdefinierte Ressource sind miteinander verbunden, aber keine Synonyme. Jedes dieser Dinge braucht eine eigene Identität und einen eigenen Nachfolgezustand.

Roach schrieb einen Rahmen, der die Grenze bewahrt

RFC 6665 erschien im Juli 2012 auf dem Standards Track und ersetzte RFC 3265. Adam Roach ist bei beiden Dokumenten der allein genannte Autor. Sein aktuelles IETF-Profil verzeichnet eine Mitwirkung seit 1998, die Tätigkeit als Applications and Real-Time Area Director von 2017 bis 2020 sowie frühere Vorsitze bei XCON, SIPCORE und NETVC. Es nennt 23 RFCs und zum Stand 22. April 2026 keine aktive Rolle.

Diese Angaben belegen Standardisierungsarbeit, nicht die Kontrolle einer konkreten Implementierung. Zuordnung der Gründe, Timer-Politik und Anzeige gehören dem Produkt und seinen Betreibern. Roachs Name gibt dem Rahmen Herkunft; er zertifiziert weder ein Produkt noch eine Schlussfolgerung über eine Ressource.

Das Evidenzpaket muss fünf Fragen getrennt beantworten

Zur Identität: Welcher Dialog, welches Paket, Ziel und welcher lokale Schlüssel? Zum Lebenszyklus: Welcher Zustand, Grund, Ablaufmechanismus und Empfangszeitpunkt? Zur Ressource: Gab es einen Körper, welches Paket interpretierte ihn, und welche Digest- und Versionsdaten wurden bewahrt? Zur Transportkette: Welcher Notifier, welche Authentifizierung, Transaktion und Antwort? Zur Handlung: Wurde erneut versucht, gewartet, migriert, alarmiert oder geschlossen, und nach wessen Regel?

Diese Trennung bremst Automatisierung nicht. Ein timeout kann einen Beobachtungsausfall melden, ohne die Ressource für tot zu erklären. deactivated kann bis zum ersten NOTIFY des Nachfolgeabonnements offen bleiben. noresource kann vor einem unumkehrbaren Schritt zusätzliche Bestätigung der Anwendung verlangen. Ein fehlender Grund lässt sich ehrlich als unbekannt darstellen.

Der Einwand, der Betrieb brauche einen kompakten Zustand, ist berechtigt. Dieser Zustand sollte exakt zusammenfassen, was bewiesen ist: Abonnement beendet, Grund bekannt oder unbekannt, Ressourcenevidenz vorhanden oder nicht. Rot bleibt nützlich, wenn seine Legende die Wahrheit sagt.

Quellen