Zusammenfassung

  • Ein UAS kann im 200 melden, ob es manuell oder automatisch antwortete. Da Manual Anwesenheit offenlegen kann, ist Weglassen der empfohlene Standard; Abwesenheit bleibt unbekannt.
  • Priv-Answer-Mode beantragt eine strengere privilegierte Prüfung. ;require verlangt Ablehnung statt eines anderen Modus, während Require: answermode nur Erweiterungsverständnis verlangt.
  • Automatisch angenommene Eingangsmedien berechtigen keine spätere Mikrofonfreigabe. Der UAS muss Richtungsänderungen im Dialog verfolgen und vor eigener Aussendung explizite Nutzerannahme erhalten.

Eine ausgelassene Aussage durfte nicht erfunden werden

Der Antwort-Header kann einer Push-to-talk-Sprecherin helfen: Bei Manual spricht sie anders als bei einem unbeaufsichtigten Lautsprecher. Dieselbe Information kann aber verraten, dass ein Mensch am Gerät gehandelt hat. Die RFC verlangt deshalb konfigurierbare Offenlegung und empfiehlt Auslassen als Voreinstellung.

Ein Datenmodell mit Pflichtwert answer_mode erzeugt hier leicht falsche Tatsachen. null darf nicht zu Auto werden, nur weil keine Bedienung beobachtet wurde. Es darf auch nicht zu Manual werden, weil ein Gespräch später menschlich wirkte. Der SIP-Beleg hat die Information nicht geliefert.

Selbst ein vorhandenes Feld bleibt eng. Manual berichtet eine definierte UI-Interaktion, nicht die Identität der handelnden Person. Auto berichtet fehlendes Warten auf diese Interaktion, nicht Abwesenheit, Gehör, Verständnis oder Zustimmung zu einer späteren Aufzeichnung.

Der Anforderer bestimmte nicht die Zielrichtlinie

Answer-Mode: Auto bittet um Annahme ohne Nutzerinteraktion. Der UAS entscheidet anhand authentifizierter Identität, lokaler Autorisierung, Nutzerpräferenzen und Medienrisiko. Er kann manuell behandeln oder ablehnen.

Mit Auto;require ist manueller Ersatz ausgeschlossen. Wählt die Richtlinie nicht Auto, muss der UAS ablehnen. Das Parameterwort wird nach der Richtlinienentscheidung ausgewertet und verleiht dem UAC keine zusätzliche Macht.

Require: answermode betrifft dagegen Protokollunterstützung. Ein verstehender UAS darf weiterhin ablehnen. Auch REGISTER-Merkmal und Accept-Contact beweisen nur deklarierte Fähigkeit und Auswahl eines Kontakts, nicht die konkrete Freigabe.

Priv rief eine strengere Tabelle auf

Die RFC vergleicht Priv-Answer-Mode mit sudo: Der Präfix fordert eine privilegierte Behandlung an, behauptet sie aber nicht. Standardmäßig soll der UAS ablehnen, wenn der Anforderer nicht authentifiziert und ausdrücklich für diese Behandlung autorisiert ist.

Dieselbe Identität kann gewöhnlich höflich anrufen und nur in einem Notfall die privilegierte Richtlinie verlangen. Eine pauschale Hochstufung nach Namen zerstört diese Absicht. Treffen beide Header ein, prüft der UAS zunächst Priv und verarbeitet bei fehlender Berechtigung den gewöhnlichen Header.

RFC 4474 war 2008 ein genannter Identitätsmechanismus und wurde später durch RFC 8224 ersetzt. Das historische Zitat belegt keine heutige Verbreitung; es unterstreicht die Trennung von Identitätsnachweis und Autorisierungsentscheidung.

Medienrichtung war eine eigene Berechtigungsachse

Eingangsmedien können über Lautsprecher stören, Kosten verursachen oder die Batterie belasten. Ausgangsmedien können Mikrofon oder Kamera zur Fernbeobachtung machen. Deshalb verbietet die Minimalrichtlinie UA-erzeugte Ausgangs- oder bidirektionale Medien ohne ausdrückliche Nutzerannahme.

Diagnostischer Loopback ist die Ausnahme, weil das Prüfsignal zurückläuft und nicht der Raum aufgenommen wird. Unbekannte oder nicht autorisierte Identitäten sollten auch keinen automatischen Eingang erhalten.

Ein Dialog kann eingangsseitig beginnen und durch re-INVITE oder UPDATE auf sendrecv wechseln. Answer-Mode ist in solchen Mid-Dialog-Anfragen nicht definiert; die Schutzpflicht endet trotzdem nicht. Zustandsbehaftete Prüfung muss die Änderung blockieren, bis ein neuer Nutzerbeleg vorliegt.

Parallel Forking machte das Endergebnis unvollständig

Mehrere registrierte Kontakte können denselben INVITE erhalten und automatisch 200 senden. SIP behält typischerweise den ersten Dialog und beendet die anderen mit BYE. Ein unterlegener Apparat kann vorher bereits Ton abgespielt haben.

Darum empfiehlt die RFC Auto-Antwort nicht bei parallelem Forking. Ein Audit braucht jede Branch, ihren Kontakt, 200-Zeitpunkt, Medienbeginn und BYE. Der eine verbleibende Dialog ist keine vollständige Handlungsgeschichte.

Ein Proxy durfte nur kraft Vereinbarung ändern

Gewöhnliche Zwischenproxies ignorieren die Felder. Ein Serving Proxy darf sie nur auf Grundlage einer ausdrücklichen externen Vereinbarung mit dem bedienten Nutzer einfügen, löschen oder ändern. Diese delegierte Autorität muss im Herkunftsnachweis erscheinen.

Speichert man nur den finalen INVITE, verschmelzen Anruferabsicht und Proxy-Politik. Original, Transformation, Proxy-Identität, Vereinbarungsversion und vom UAS bewertete Bytes gehören zusammen.

Beweisgrenze

Der belastbare Datensatz verbindet initialen INVITE, Identität, gewöhnlichen oder privilegierten Antrag, beide require-Bedeutungen, Kontaktwahl und Forks, Proxy-Änderungen, UAS-Richtlinie, Antwort und Offenlegung, SDP-Richtung je Dialogversion, Nutzerannahme und tatsächlich ausgehende Pakete. Menschliche Aufmerksamkeit und Ergebnis bleiben getrennt.

Damit ist die Aussage möglich, dass ein UAS einen Antrag nach einer Richtlinie behandelte. Eine ausgelassene Antwort wird nicht zur erfundenen Gewissheit.