Zusammenfassung

  • RFC 3428 erlaubte einem SIP-Proxy, eine MESSAGE-Anfrage an mehrere mögliche Endgeräte zu verzweigen und dem Absender dennoch nur eine Abschlussantwort weiterzuleiten.
  • Aus dieser Antwort ließ sich weder eine Verzweigung noch die Zahl der empfangenden User Agents erkennen; sie bewies auch nicht, dass ein Mensch die Nachricht gelesen hatte.

Diese Abweichung gehörte zum Protokollmodell und war für sich genommen kein Hinweis auf einen Dienstfehler. RFC 3428 ergänzte SIP um MESSAGE für eigenständige, pagerartige Sofortnachrichten. Eine MESSAGE-Anfrage eröffnet selbst keinen SIP-Dialog. Proxys leiten sie nach den SIP-Regeln weiter; ein nachgelagerter Proxy kann sie an mehrere Geräte verzweigen, unter denen der Empfänger erreichbar sein könnte.

Damit entstehen zwei Ansichten derselben Transaktion. Mehrere Zweige können nach dem Empfang der Nachricht erfolgreiche Antworten liefern. Der verzweigende Proxy leitet jedoch nur eine Abschlussantwort nach oben weiter. RFC 3428 hält fest, dass der sendende User-Agent-Client eine Verzweigung nicht erkennen kann und aus der einzelnen sichtbaren Antwort nicht schließen darf, nur ein User Agent habe die Anfrage erhalten. Die Zahl der Antworten auf Senderseite ist keine Empfängerzählung.

Der Statuscode bleibt wichtig, beantwortet aber eine andere Frage. Im gewöhnlichen Fall einer Antwort vom endgültigen Ziel darf der sendende Client bei 200 OK annehmen, dass die Nachricht dieses Ziel erreicht hat. Daraus folgt nicht, dass der Nutzer sie gesehen oder gelesen hat. Ein User Agent darf antworten, bevor er die Nachricht anzeigt, und muss sie überhaupt nicht anzeigen. 202 Accepted bedeutet lediglich, dass ein Gateway, Store-and-Forward-Server oder ein anderer Dienst die Nachricht angenommen hat; die Zustellung an das endgültige Ziel ist damit nicht belegt. Eine solche Bestätigung erfordert laut RFC 3428 einen anderen, außerhalb des Dokuments liegenden Mechanismus.

Bei der Rekonstruktion eines Ablaufs kann der Absender also eine Transaktion und eine Abschlussantwort sehen, während nachgelagerte Protokolle mehrere erfolgreiche Zweige zeigen. Das ist kein Widerspruch. Umgekehrt belegt ein einzelnes vorgelagertes 200 weder eine genau-einmalige Zustellung noch die Zahl empfangender Geräte oder menschliche Aufmerksamkeit. RFC 3428 definiert eine Möglichkeit; es belegt keinen realen Vorgang bei einem benannten Dienst.

Auch das Kommunikationsmodell war eng umrissen: Jede MESSAGE steht für sich; ein Gesprächszusammenhang kann allein in der Oberfläche oder der Vorstellung der Nutzer entstehen. Das RFC unterscheidet dieses Pager-Modell von einer Sitzung mit explizitem Anfang und Ende. RFC 8591 aktualisierte und präzisierte später Teile der S/MIME-Behandlung bei SIP-Nachrichten. Es machte eine SIP-Antwort jedoch weder zum Lesebeleg noch änderte es die hier untersuchte Zählgrenze bei Verzweigungen.

Quellen: RFC 3428, Abschnitte 2–8; RFC 3261 zu SIP-Routing und Proxy-Verhalten; RFC 8591 zu späteren S/MIME-Aktualisierungen. Der vollständige Satz: