Zusammenfassung

  • Nach RFC 4028 verlängert nur die 2xx-Antwort auf einen In-Dialog-re-INVITE oder UPDATE die Ablaufzeit. Versand, sichtbarer Traffic oder 422 sind noch kein Refresh.
  • Session-Expires, Min-SE und refresher verteilen Zeit-, Erneuerungs- und Aufräumpflichten. Sie belegen weder RTP noch menschliche Anwesenheit, Qualität, Einwilligung oder Abrechnungsrecht.
  • Belastbare Entscheidungen halten Transaktion, Dialog, Medien, Anwendung und kommerziellen Zustand getrennt und führen sie erst mit Herkunft und Zeitbezug zusammen.

Ein grünes Signal neben einem stummen Kanal

In einer Unternehmensplattform läuft die SIP-Signalisierung über einen zustandsbehafteten Proxy, der RTP-Strom nimmt einen anderen Weg. Der Refresher sendet einen UPDATE ohne SDP und erhält 200 OK. Der Proxy verschiebt seine lokale Ablaufzeit. Zugleich hat ein unabhängiger Fehler den Ton in einer Richtung beendet; RTCP-Berichte fehlen, der Nutzer hat das Gerät verlassen, doch die Software sendet weiter automatische Refreshes.

Eine Abrechnung, die „session refreshed“ als „Leistung fortgesetzt“ liest, verlängert die Rechnung. Dafür muss keine Timer-Implementierung defekt sein. Die Transaktion kann korrekt und der Medienpfad tot sein. Der Fehler ist eine Überschreitung der Beweisgrenze.

RFC 4028 löst ein engeres Problem. Ein UA kann BYE nicht senden, oder BYE geht verloren; call-stateful Proxies behalten dann Zustand. Periodische re-INVITEs oder UPDATEs schaffen eine begrenzte Gültigkeit für SIP-Sitzungszustand. Die Spezifikation grenzt diesen Mechanismus ausdrücklich von medienspezifischer Lebensprüfung wie RTCP ab.

Der Session-Timer ist kein universeller Herzschlag. Er hält eine bestimmte Art von Zustand unter bestimmten Bedingungen gültig.

Drei Zeiten hinter demselben Feld

Das Session-Intervall ist die längste zulässige Spanne zwischen erfolgreichen Refreshes. Der operative Wert stammt aus Session-Expires in der maßgeblichen letzten 2xx-Antwort.

Der Mindesttimer bezeichnet das kürzeste Intervall, das ein Element akzeptiert. In-Dialog-Anfragen kosten Kapazität; Min-SE verhindert, dass eine Seite einen übermäßigen Takt erzwingt.

Die Ablaufzeit ist dagegen lokal berechnet. Der UAS zählt ab Versand seines 2xx, der UAC ab Empfang, ein Proxy ab dem von ihm weitergeleiteten Ereignis. Laufzeit und Verarbeitung trennen diese Fristen. Es gibt keinen global beglaubigten Zeitpunkt.

„Intervall 1.800 Sekunden“ verrät deshalb nicht, welche Antwort es setzte, wann jedes Element zu zählen begann, wer erneuern musste oder ob ein späteres 2xx den Timer entfernte. Eine Rekonstruktion braucht Quellereignis und lokalen monotonen Deadline-Wert.

Der Pfad verhandelt mit

Ein UAC kann mit der Option timer Unterstützung anzeigen und ein Intervall vorschlagen. Zustandsbehaftete Proxies dürfen den Timer verlangen, Session-Expires verkürzen oder Min-SE anheben, jedoch nicht unter die akkumulierte Untergrenze gehen.

Der UAS liefert im 2xx das Endergebnis und den Parameter refresher=uac oder refresher=uas. Proxies sehen den Rückweg, dürfen den finalen Wert aber nicht neu schreiben.

Ist der Vorschlag zu klein, kommt 422 Session Interval Too Small samt Min-SE. Der UAC kann mit höherem CSeq und größerem Wert eine neue Transaktion beginnen. Das ist Konvergenz von Randbedingungen, noch keine Verlängerung. Erst 2xx bewegt die Frist.

Ein 422 kurz vor Ablauf ist daher gefährlich: Der zukünftige Wert ist bekannt, der neue Versuch muss trotzdem vor dem alten Ende gelingen. Wer nur den späteren 200er speichert, löscht das eigentliche Risikofenster.

Die Untergrenze schützt auch vor Lastverstärkung. Ein 422-Anstieg kann Route, Policy, Überlastschutz, Fehlkonfiguration oder Angriff bedeuten. Der Statuscode allein entscheidet die Ursache nicht.

uac und uas sind keine Personen

refresher weist die nächste Erneuerung zu. Er bezeichnet nicht dauerhaft Anrufer, Kundenkonto oder zahlende Partei. UAC und UAS sind Rollen einer Transaktion; der Empfänger des initialen INVITE kann als Sender eines späteren UPDATE selbst UAC werden.

Darum ist refresher=uac ohne Zuordnung unbrauchbar. Das Protokollereignis muss Rolle, konkreten Endpoint, Dialog, Methode, CSeq und Richtung verbinden.

Forking schafft mehrere Dialoge aus einem INVITE. Jeder kann ein anderes Intervall, einen anderen Refresher und eine eigene Frist besitzen — oder keinen Timer. Ein erfolgreicher Zweig hält keinen Nachbarzweig am Leben. Fehlt Session-Expires im jüngsten 2xx, kann der Timer außerdem mitten im Dialog ausgeschaltet sein.

Nur ein Ereignis verschiebt die Grenze

RFC 4028 zieht eine harte Linie: Nur ein 2xx auf den Refresh verlängert den Zustand. UPDATE gesendet, provisorische Antwort, 401/407, 422, erfolgreicher Socket-Write oder Sichtbarkeit am Proxy reichen nicht. Ein authentifizierter Folgeversuch kann später erfolgreich sein; er macht den ersten nicht rückwirkend gültig.

Bei Timeout, 408 oder 481 sendet der erfrischende UA nach den SIP-Regeln BYE. Andere Fehler können begrenzte Wiederholung erlauben, keine Endlosschleife.

Der Nicht-Refresher wartet auf die Erneuerung und soll BYE etwas vor Ablauf senden. Empfohlen ist das Minimum aus 32 Sekunden und einem Drittel des Intervalls, weil Firewall oder NAT-ALG am exakten Ende bereits schließen können.

Der Proxy besitzt weniger Vollmacht. Nach lokaler Frist darf er Zustand und Ressourcen löschen, aber kein BYE im Namen eines Endpunkts erzeugen. Sein Ledger darf enden, ohne dass das Gespräch dadurch universell endet.

So können Medien nach Proxy-Cleanup weiterlaufen, BYE kann auf einer Seite verloren gehen, lokale Deadlines können auseinanderliegen. Ein nachträglich erzeugter einziger Hangup-Zeitpunkt wäre Scheingenauigkeit.

Ein Refresh kann die Sitzung verändern

Re-INVITE und UPDATE bleiben normale SIP-Methoden. RFC 3311 lässt UPDATE Sitzungsinformationen und Remote Target verändern. RFC 3261 bindet re-INVITE an Dialog-, Target- und Offer/Answer-Regeln.

Für reine Erneuerung empfiehlt RFC 4028 einen offerlosen UPDATE, sofern unterstützt. Re-INVITE trägt normalerweise ein Angebot, selbst wenn das SDP unverändert ist. Ein Request für Hold, Wiederaufnahme oder Medienwechsel kann den Timer nebenbei auffrischen.

Neben demselben 2xx können daher Contact, SDP, Richtung, Codec, Adresse, Authentisierung oder eine Request-Kollision geändert sein. RFC 6141 behandelt re-INVITE, 491 und Zustandswiederherstellung, weil es sich nicht um einen simplen Ping handelt.

Die Evidenz muss Absicht, SDP-Präsenz und -Hash, Origin-Version, Streamrichtung, Contact und abschließende Antwort enthalten.

Signalisierung und Medien haben eigene Tatsachen

RFC 3264 verhandelt sendrecv, sendonly, recvonly, inactive oder Ablehnung. Das sind Sollzustände, keine Paketzustellnachweise.

RFC 3550 garantiert für RTP weder Zustellung noch Dienstgüte. RTCP liefert Empfangsberichte, Zeit- und Teilnehmerdaten. Es ist wichtige Fluss- und Qualitätsevidenz, beweist aber nicht Zuhören, Verständnis, Einwilligung oder Geschäftswert.

Mindestens fünf Ebenen gehören getrennt: SIP-Transaktion; Dialog und Timer; RTP/RTCP; Anwendung und menschliche Handlung; Berechtigung, Abrechnung und Compliance. 2xx ist auf den ersten beiden stark und auf den letzten drei fast stumm.

Medien können bei fortgesetztem Refresh sterben; Medien können bei Signalisierungsausfall weiterlaufen; ein Stream kann absichtlich inactive sein; Software kann ohne Nutzer erneuern. Heng Lus Trennung symbolischer und praktischer Macht wird hier zur Betriebsregel: Ein korrektes Symbol besitzt keine automatische Souveränität über die Ausführung.

Hop-by-Hop-Integrität hat ebenfalls eine Grenze

Proxies verändern Timer-Felder legitim. End-to-End-S/MIME kann ein Feld nicht schützen, das Zwischenstellen bearbeiten müssen. RFC 4028 empfiehlt deshalb TLS auf relevanten Hops und SIPS.

Das erschwert fremde Manipulation von Intervall und Last, soweit die Kette geschützt ist. Es macht aus dem Feld dennoch keine Medien- oder Abrechnungsattestation.

Das Errata-Verzeichnis zu RFC 4028 enthält verifizierte Korrekturen zur UAC/UAS-Terminologie. Eine im Mai 2026 gemeldete Frage zum Proxy-Verhalten bei explizitem refresher=uas ist weiterhin Reported. Sie gehört in Interoperabilitätstests, nicht als vermeintlich geändertes Recht in eine Policy.

Ein beweisfähiger Verlauf

Ein belastbarer Datensatz bindet Dialogidentität und tatsächliche Endpoint-Rollen an jede Transaktion. Er bewahrt Methode, CSeq, Branch, Route, Timer-Felder vor und nach Zwischenstellen, Zeitpunkte, lokale Fristen und das entscheidende 2xx.

Hinzu kommen SDP-Präsenz und Hash, Offer/Answer-Version, Richtungen, Contact, Challenges und Wiederholungen. BYE braucht Absender und Ursache: Nutzerhandlung, Refresh-Fehler, Peer-Ablauf oder Policy.

Medien und Anwendung bleiben unabhängige Beweisquellen. Da SIP Identität und Topologie offenlegt, kann das Original zugriffsbeschränkt bleiben, während allgemeine Telemetrie verknüpfbare Projektionen oder Hashes nutzt.

Tests brauchen 422 kurz vor Ende, 401 mit erfolgreicher Wiederholung, 408, 481, fehlenden Refresh beim Peer, Proxy-Cleanup ohne BYE, tote Medien bei frischem SIP, Medien nach Signalisierungsverlust, verschiedene Forks, Timer-Abschaltung, offerlosen UPDATE, re-INVITE mit SDP-Änderung, Target-Refresh, Zustandsverlust beim Failover und ungeschützten Hop.

Das Ergebnis ist kein grünes Bit, sondern eine Chronik: Welche Ebene lebte, welche nicht, und wer durfte aus welchem Grund handeln?

Quellen