Zusammenfassung

  • 201 Created belegt nach RFC 9725 die Annahme des SDP-Angebots, die SDP-Antwort und die Anlage einer Session-Ressource. Es belegt weder einen nominierten ICE-Pfad noch DTLS oder dauerhaft ankommendes SRTP.
  • Ein belastbarer Live-Nachweis braucht getrennte Quittungen für Konnektivität, kryptografischen Kontext, zeitlich beobachtete Medien, aktuelle Verarbeitung, CDN-Auslieferung und Wiedergabe beim Zuschauer.
  • DELETE schließt den HTTP-Lebenszyklus; der betriebliche Abschluss ist erst belegt, wenn die passende Mediengeneration gestoppt und abhängige Kapazität freigegeben wurde.

Das Kontrollsignal ist schneller als das Programm

Im Idealfall antwortet ein WHIP-Endpunkt sehr schnell. Der Encoder sendet sein JSEP-Angebot als application/sdp, der Dienst erzeugt eine SDP-Antwort und nennt unter Location die neue Session-Ressource. Ein Orchestrator sieht 201 Created und setzt den Status auf Grün. Hinter diesem Grün kann die Medienebene noch vollständig dunkel sein.

Genau diese Enge ist im RFC 9725 beabsichtigt. Der RFC-Editor-Eintrag und der IETF Datatracker datieren den Proposed Standard auf März 2025; die Errata-Suche enthielt zum Rechercheabschluss keinen einschlägigen Eintrag. Das sind Angaben zur Norm, keine Prüfung eines Produkts.

Die Bedeutung von 201 folgt den HTTP-Semantiken des RFC 9110: Eine Zielressource wurde angelegt. Der Endpunkt hat das Angebot verarbeitet und kann spätere PATCH- oder DELETE-Anfragen adressieren. Daraus folgt nicht, dass UDP den Empfänger erreicht, der DTLS-Handshake gelingt, der Encoder Frames liefert oder ein Zuschauer etwas sieht.

Die eine Session besitzt mehrere Wahrheiten

WHIP begrenzt den Start auf einen Offer/Answer-Austausch und erlaubt danach keine gewöhnliche Neuverhandlung von Nicht-ICE-Mediendaten. Eine Session verwendet einen MediaStream, Bündelung und gemultiplextes RTP/RTCP. Der Client bietet typischerweise sendonly, der Server antwortet recvonly. Die Einschränkung reduziert Interoperabilitätsfläche, nicht die Zahl der betrieblichen Übergänge.

Mindestens sieben Zustände bleiben: HTTP-Annahme; ICE-Auswahl; DTLS und SRTP; Beginn und Stabilität der Medien; Verarbeitungsbereitschaft; Distribution und Wiedergabe; Abbau. Jeder Zustand braucht Zeitstempel, Beobachtungsfenster und einen benannten Zeugen. Ein einziges Feld „live“ kann die Reihenfolge darstellen, aber keine widersprüchlichen Befunde bewahren.

Die 201-Antwort darf über Link-Header auch STUN- oder TURN-Server anbieten, gestützt auf die Web-Linking-Regeln des RFC 8288. Ein solcher Link belegt weder erreichbaren Relay noch gültige Zugangsdaten noch ausreichende Relay-Kapazität.

ICE-Beschreibung und ICE-Verbindung sind nicht dasselbe

Nach RFC 8445 sammelt ICE Kandidaten, bildet Paare, prüft sie per STUN und nominiert schließlich ein Paar. Kandidaten im SDP sind deshalb Eingaben für eine Entscheidung, nicht das Ergebnis der Entscheidung.

Trickle ICE verschärft diese zeitliche Trennung. Nach der POST-Antwort kann der Client weitere Kandidaten per PATCH als application/trickle-ice-sdpfrag schicken. Das Fragmentformat stammt aus RFC 8840, die Methode aus RFC 5789. Der Server darf mit 204 No Content quittieren und dennoch einen Kandidaten mit unbekanntem Transport oder nicht auflösbarer Adresse still verwerfen. 204 belegt also die Verarbeitung des Fragments, nicht die Nutzbarkeit seiner Bestandteile.

Die Netzwerkquittung sollte ICE-Generation, ausgewähltes Paar, direkt oder Relay, lokale und entfernte Tupel, Nominationszeit und späteren Consent-Zustand enthalten. Bei einem ICE-Restart schützen starke ETags die Generation. Fehlende Bedingungen führen zu 428 Precondition Required, veraltete zu 412 Precondition Failed. Eine 200-Antwort mit neuen Credentials, Kandidaten und ETag ist eine neue Beschreibung; die Verbindungstests folgen erst.

DTLS schützt Pakete, erzeugt aber keine Sendung

RFC 5764 leitet im DTLS-SRTP-Verfahren SRTP-Schlüsselmaterial aus dem DTLS-Handshake ab. Die WebRTC-Transportanforderungen des RFC 8835, die RTP-Regeln des RFC 8834 und JSEP im RFC 9429 ordnen die Verbindung ein. Ein abgeschlossener Handshake belegt einen kryptografischen Kontext. Er belegt keine gesendeten Frames und keine kompatible Dekodierung.

Ein Medienbeleg ist eine Zeitreihe: erster und letzter Empfang, fortschreitende Paket- und Oktettzähler, SSRC, erwartete MID/RID-Zuordnung, Sequenzkontinuität, Verlust, Jitter, Bitrate sowie RTCP- oder Transportfeedback. Das erste Paket ist ein Meilenstein; ohne Fenster sagt es fast nichts über Stabilität.

Die Staukontrollanforderungen des RFC 8836 verhindern eine weitere falsche Abkürzung. Eine Quelle kann kurzfristig hohe Bitrate liefern und zugleich den gemeinsamen Pfad überlasten. Erfolg bedeutet auch, dass Feedback vorhanden ist und die Quelle sinnvoll darauf reagiert.

Hinter dem Ingest beginnt die Beweiskette neu

RFC 9725 bringt WebRTC-Medien in einen Streamingdienst oder ein CDN. Er standardisiert nicht Decoder, Transcoder, Packager, Origin, Request Routing, Cache oder Player. Das CDNI-Framework in RFC 7336 trennt diese Funktionen. RFC 7937 zeigt zudem, dass Auslieferungslogs erzeugt, aggregiert, gefiltert, gesammelt und berichtigt werden können.

Ein Ingest-Team kann belegen, welche SRTP-Pakete sein Empfänger sah. Eine Verarbeitungsplattform kann dekodierte Eingaben und fortschreitende Renditions belegen. Die Distribution kann aktuelle Objekte und begrenzte Messpunkte belegen. Ein Player-Probe kann Startzeit, Audio-/Videofortschritt und Unterbrechungen von einem benannten Standort belegen. Keine Stufe darf das Grün der vorherigen ohne eigene Prüfung erben.

Das gilt auch für negative Evidenz. Keine Beschwerde ist keine Player-Quittung. Kein Verlustbericht ist nicht null Verlust. Kein CDN-Alarm ist kein Beweis vollständiger Abdeckung. Jede Aussage muss ihr Messfenster und ihre Blindstellen nennen.

Autorisierung ist schon vor dem ersten Paket eine Kapazitätsentscheidung

WHIP verlangt HTTP-Authentifizierung und interoperablen Umgang mit Bearer Tokens. Verteilung und Bedeutung des Tokens bleiben außerhalb des RFC. Ein akzeptiertes Token kann Zugang zum Endpunkt erlauben, ohne jedes Ereignis, jede Region, Bitrate, Laufzeit oder Kostenstelle zu autorisieren.

Schon der POST kann Session-Zustand reservieren. Ein berechtigter Client kann viele Sessions erzeugen, die nie ICE oder DTLS erreichen. RFC 9725 behandelt POST- und PATCH-Flooding, Rate Limits und Wiederverbindungswellen. Ratbare Session-URLs sind ebenfalls riskant, weil ein fremdes DELETE eine Übertragung beendet.

Kapazitätssteuerung sollte daher Kohorten zählen: erstellt, aber nicht verbunden; verbunden, aber ohne DTLS; sicher, aber ohne Medien; Medien instabil; Ingest bereit, aber nicht verteilt; verteilt, aber ohne Player-Beleg; gelöscht, aber noch nicht vollständig freigegeben. Alter und gebundene Ressourcen je Kohorte sind aussagekräftiger als die Zahl aller Sessions.

Für Lastverteilung kann der erste POST mit 307 Temporary Redirect umgeleitet werden, wodurch Methode und Body erhalten bleiben. Unterstützung für Umleitungen von PATCH und DELETE ist nicht vorausgesetzt. Der Auditpfad muss daher Ursprung, Redirect-Kette, endgültige Session-Autorität und tatsächlichen Medienserver verbinden.

Ein DELETE ist ein Auftrag, keine abgeschlossene Bilanz

Der Client sendet DELETE an die in Location genannte URL. RFC 9725 beschreibt die Entfernung der Ressource, Freigabe von Medienserver-Ressourcen und das Ende von ICE und DTLS. Consent Freshness nach RFC 7675 schützt bei unvollständigem Abbau davor, weiter auf einem Five-Tuple zu senden. Es ist Transporterlaubnis, keine menschliche Einwilligung und kein Medienerfolg.

Der Abschlussbeleg nennt die Session und Generation, den auslösenden Akteur und Grund, das Ende der Ingress-Zähler sowie die Freigabe von TURN, Decoder, Transcoder, Packager und Origin. Eine HTTP-200-Antwort kann den Auftrag quittieren. Erst der Rückgang der zugehörigen Zustände belegt die Rückgewinnung der Kapazität.

Das folgt der Running-Code Primacy: Maßgeblich sind der laufende Dienst und seine Abhängigkeiten, nicht die administrative Darstellung. Die Idee einer minimalen gemeinsamen Spezifikation mit lokalisierten Folgeentscheidungen erklärt, warum WHIP schmal bleiben darf und Betreiber trotzdem eigene Regeln für Berechtigung, Kapazität und Nachweis tragen. Der Realitätsansatz aus Why BTW.Media Exists verlangt, Widersprüche festzuhalten: HTTP grün, Medien fehlen; Ingest grün, Zuschauer scheitern; DELETE bestätigt, Ressourcen gebunden.

Sources

Primäre Spezifikationen: RFC 9725, RFC-Editor-Eintrag, IETF Datatracker, Errata-Suche, RFC 8445, RFC 7675, RFC 5764, RFC 8834, RFC 8835, RFC 8836, RFC 8840, RFC 9429, RFC 9110, RFC 5789, RFC 8288, RFC 7336 und RFC 7937.

Zugeordneter Analyserahmen: Running-Code Primacy, Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption und Why BTW.Media Exists — and Why Reality, Not Advocacy, Is the Product.