Zusammenfassung

  • Die Konferenzanwendung von RFC 5366 benötigt eine flache URI-Liste. Zusätzliche RFC-4826-Struktur kann verworfen werden; ein 200 bestätigt daher Listenverständnis, nicht die vollständige Bewahrung jeder Eingabeabsicht.
  • Derselbe 200 bestätigt Konferenzerstellung und Teilnahme des anfragenden UAC, aber keinen Einladungs-, Aufnahme-, Dialog- oder Medienerfolg für andere Listeneinträge.
  • Die Listenoperation gehört zum anfänglichen INVITE an die Fabrik-URI. Die zurückgegebene Konferenz-URI ist eine andere Ressource; eine Liste im re-INVITE hat keine definierte Semantik und führt mit Require zu 420.

Ein reiches Format traf auf einen schmalen Dienst

RFC 4826 kann mehr ausdrücken, als die Konferenzfabrik benötigt. Listen können verschachtelt sein und Einträge relativ zu einer XCAP-Wurzel referenzieren. RFC 5366 beschränkt seinen Anwendungsfall auf eine flache Liste von Ziel-URIs.

Der Client sollte deshalb keine Hierarchie und keine relativen Eintragsverweise verwenden. Erhält die Fabrik dennoch zusätzliche Information, darf sie alles verwerfen, was über den beschriebenen Bedarf hinausgeht.

Das ist keine beiläufige Parsernotiz. Es bestimmt, was ein erfolgreicher Empfang beweisen kann. Der Server kann die Nachricht als gültige Anfrage zur Konferenzerstellung verstanden haben, ohne eine vom Absender gedachte Gruppierung, Herkunft oder Referenzauflösung auszuführen.

Ein Audit benötigt daher mindestens drei Fassungen: die empfangenen Bytes, das Parserergebnis und die normalisierte Zielmenge, aus der Operationen entstanden. Verworfenes Material braucht einen Grund. Sonst kann der Absender auf eine Struktur zeigen, die im Server nie handlungswirksam war, während der Server nur die flache Menge kennt.

Ein gemeinsamer Listenbezeichner löst das Problem nicht. Zwei Parserstände können aus denselben Bytes unterschiedliche normalisierte Mengen bilden. Ein Fingerabdruck der Eingabe muss mit Parser- und Regelversion sowie dem Fingerabdruck des Ergebnisses verbunden werden.

Verstanden heißt nicht eingeladen

Auch die normalisierte Liste ist noch kein Ausführungsnachweis. RFC 5366 sagt ausdrücklich, was die 200-Antwort auf den ersten INVITE bedeutet: Die Konferenz wurde erstellt, der anfragende UAC befindet sich darin, und der Server hat die Liste verstanden.

Die Antwort enthält keine Aussage darüber, ob andere Benutzer in die Konferenz gebracht wurden. Nach der Erstellung soll der Server versuchen, die Teilnehmer hinzuzufügen. Jeder Versuch kann separat scheitern.

Ein Ziel kann syntaktisch gültig, aber nicht erreichbar sein. Ein INVITE kann abgelehnt werden. Ein Endpunkt kann antworten, ohne die geforderte Identität zu belegen. Der focus kann die Identität akzeptieren, aber bestimmte Medien verweigern. Ein Dialog kann entstehen, während der Medienpfad unbrauchbar bleibt.

Das Datenmodell muss diese Stufen abbilden. list_understood gehört zum Eingangsparser. invite_generated gehört zum Ausführer. authenticated und admitted gehören zum focus. dialog_established gehört zur Signalisierung. media_observed gehört zum Laufzeitpfad.

Wer sie in participant=true zusammenfasst, verwandelt unbekannte oder negative Ergebnisse in Erfolg. Besonders problematisch ist das bei Quorum, Zustimmung, Abrechnung oder der Behauptung, eine Person habe Gelegenheit zur Teilnahme gehabt.

Die Fabrik erzeugt eine neue Autoritätsfläche

Der erste INVITE richtet sich an eine Konferenzfabrik. Die Antwort liefert in Contact die eigentliche Konferenz-URI und kennzeichnet sie als focus. Ab diesem Moment adressiert der bestehende Dialog die neue Ressource.

Die Fabrik kann recipient-list-invite unterstützen. Diese Fähigkeit gehört zur Erstellung. Sie geht nicht allein deshalb auf die Konferenz-URI über, weil beide URIs vom selben Produkt oder Host bedient werden.

OPTIONS muss mit seiner Ziel-URI gespeichert werden. Eine Antwort der Fabrik beweist nicht, dass ein späteres re-INVITE an die Konferenz dieselbe Listenerweiterung nutzen kann. Ein Capability-Scanner, der nur den Host inventarisiert, erzeugt eine falsche Reichweite.

Umgekehrt ist eine Ablehnung an der Konferenz-URI kein Beweis, dass RFC 5366 insgesamt fehlt. Sie kann zeigen, dass der Server die Ressourcengrenze korrekt durchsetzt.

Die Zuordnung zwischen Fabrikanfrage und erzeugter Konferenz braucht einen dauerhaften Beleg: Anfangstransaktion, zurückgegebener Contact, focus-Identität, interne Konferenzkennung und Dialog des Erstellers. Ohne diese Kante lassen sich spätere Einladungen und Zustandsmeldungen nicht sicher zur ursprünglichen Liste zurückführen.

420 schützt vor erfundener Semantik

Ein re-INVITE kann Eigenschaften der Medien zwischen dem bestehenden UAC und dem Konferenzserver ändern. Für einen recipient-list-Body im re-INVITE definiert RFC 5366 keine Semantik. Clients sollten ihn dort nicht senden.

Fordert ein Client trotzdem recipient-list-invite, antwortet die Konferenzressource nach dem SIP-Erweiterungsmechanismus mit 420 Bad Extension und nennt das Tag in Unsupported. Die Antwort betrifft diese Operation an dieser Ressource.

Sie sagt nicht, dass die Konferenz verschwunden ist. Sie sagt nicht, dass der vorhandene Medienzustand zwingend fehlschlug. Sie widerspricht nicht der Fähigkeit der Fabrik. Sie verweigert eine Bedeutungsübertragung, die der Standard nicht vorgenommen hat.

Ein automatischer Fallback, der Require entfernt, heilt das nicht. Der Empfänger muss die Erweiterung dann nicht mehr verstehen; der Listenbody erhält aber weiterhin keine definierte Wirkung. Eine Umleitung zur Fabrik kann statt einer Änderung eine zweite Konferenz erzeugen.

Die Wiederherstellung muss die gewünschte Handlung benennen. Teilnehmer zu einer bestehenden Konferenz hinzuzufügen verlangt einen dafür definierten Mechanismus aus RFC 4579. Eine neue Konferenz verlangt eine neue Fabrikanfrage. Eine Medienänderung verlangt ein re-INVITE ohne Liste.

Ein Log, das alle drei Varianten nur als Retry derselben Operation speichert, zerstört die Entscheidungsgrundlage.

Die Aufnahmeentscheidung folgt erst nach dem Ziel

Ein Listeneintrag ist die Bitte des Erstellers, eine Adresse einzuladen. Er ist kein Berechtigungsnachweis des später antwortenden Teilnehmers.

Konferenzen besitzen Regeln darüber, wer beitreten darf, welche Rolle gilt und welche Medien zulässig sind. Der focus muss den potenziellen Teilnehmer authentifizieren und die aktuelle Richtlinie anwenden.

Dabei können vier Identitäten auseinanderfallen: authentifizierter Ersteller, URI in der Liste, antwortender Endpunkt und vom focus aufgenommener Principal. Weiterleitungen, gemeinsam genutzte Adressen und mehrere Geräte sind normale Ursachen.

Der Auditdatensatz sollte die Übergänge bewahren. Nur die Endidentität zu speichern löscht die Absicht des Erstellers. Nur den ursprünglichen URI zu speichern löscht die tatsächliche Aufnahmeentscheidung. Benötigt werden Authentisierungsmethode, Richtlinienversion, Entscheidung, Zeitpunkt und Begründung.

RFC 5363 verlangt für den Listenservice außerdem Authentisierung und Autorisierung des Clients sowie Opt-in-Schutz. Diese Regeln begrenzen den Fächerungseffekt. Sie ersetzen nicht die konferenzspezifische Aufnahmeentscheidung.

SDP und Liste teilen den Umschlag, nicht den Erfolg

Der erste INVITE kann multipart sein: SDP für die Sitzung des Erstellers und die URI-Liste für anfängliche Einladungen. Der gemeinsame Transport verführt dazu, einen Status auf beide Teile anzuwenden.

Das SDP gehört zum Offer/Answer zwischen Ersteller und Server. Ausgehende Einladungen erzeugen andere Dialoge mit eigenen Beschreibungen. Codec, Adresse, Verschlüsselung und Transport können pro Teilnehmer anders ausfallen.

Erfolgreiches Audio des Erstellers beweist kein Audio der Gäste. Eine erfolgreiche Signalisierung beweist keine empfangenen Pakete. Ein aufgenommener Teilnehmer kann aufgrund der Richtlinie nur einen Teil der Medien verwenden.

Für jeden Dialog sollten SDP-Fingerabdrücke, Offer/Answer-Ergebnis, Sicherheitskontext und beobachteter Medienpfad getrennt bleiben. Wo die Wiedergabe nicht messbar ist, darf „ausgehandelt“ nicht als „gehört“ dargestellt werden.

Der Konferenzzustand ist eine spätere Beobachtung

Wer den Status anderer Benutzer erfahren möchte, soll allgemeine Konferenzmechanismen wie das Event-Paket aus RFC 4575 verwenden. Diese Quelle beobachtet den focus nach den Einladungsversuchen; sie erweitert nicht rückwirkend die 200-Antwort.

Benachrichtigungen sind versioniert und können vollständig oder partiell sein. Ein partielles Dokument braucht eine gültige Basis. Geht eine Version verloren, darf die Lücke nicht mit der Eingangsliste gefüllt werden.

Teilnehmer ändern sich über die Zeit. Jemand kann später nach einem neuen Versuch beitreten, über einen anderen Mechanismus hinzugefügt werden oder unmittelbar nach einer Meldung gehen. Der Zustand zeigt, was der focus zu einem Zeitpunkt repräsentierte.

Deshalb gehören angeforderte Ziele, focus-Operationen und beobachteter Zustand in drei Mengen. Ihre Differenzen erklären Normalisierung, Fehler, Richtlinie und Zeit. Erzwungene Gleichheit würde die nützlichsten Hinweise entfernen.

Auch ein Eintrag im Zustand beweist keine menschliche Aufmerksamkeit und keinen nutzbaren Medienempfang.

Nachweisgrenze

Die eingefrorenen Quellen belegen Standardtext, Rollen, registriertes Vokabular und normative Anforderungen. Sie belegen keine aktuelle Implementierung eines Herstellers, keinen realen Vorfall und keine gemessene Verbreitung. Die RFC-Abläufe sind Beispiele und keine Paketmitschnitte.

Die belastbare Regel lautet: Ein erfolgreich verstandenes Dokument ist ein Parser- und Dienstbeleg. Es ist weder ein Nachweis vollständiger Absichtsbewahrung noch ein Nachweis der ausgelösten Ergebnisse.