Zusammenfassung

  • EVRCWB/16000 legt die RTP-Zeitbasis fest. Es beweist weder 16-kHz-Erfassung noch einen bestimmten Encoder-Modus oder wahrgenommene Wideband-Qualität.
  • Empfangsparameter sind Präferenzen, die der Sender ignorieren darf. sendmode ist eine Zustandsmeldung, die später als die zugehörigen Medien eintreffen kann; Ausführung braucht einen eigenen Beleg.

Der Bericht zählte jede Session mit EVRCWB0/16000 als Wideband-Erfolg. Auf einem Teil der Geräte war die Audiokette auf 8 kHz eingestellt. Die Pakete waren regelkonform, die Kennzahl aber falsch.

Die Verwechslung entstand nicht aus einem ungültigen Feld. Sie entstand, weil ein gültiges Feld über eine Realität sprechen sollte, die es nie gemessen hatte.

Eine Clockrate ist eine Zeitkonvention

EVRC-WB verarbeitet 20-ms-Frames. RFC 5188 schreibt eine RTP-Clockrate von 16 kHz und einen Timestamp-Schritt von 320 pro Frame vor. Diese Regel gilt auch bei 8-kHz-Eingang oder -Ausgang.

Damit lässt sich der Medienzeitpunkt interoperabel berechnen. Daraus folgt nichts über Mikrofon, Resampler, Codec-Frontend, Lautsprecher oder menschliche Wahrnehmung. Für diese Aussagen braucht es Geräte- und Anwendungsevidence.

Ein Bestandsmodell sollte deshalb getrennte Felder führen: RTP clock, Encoder-Input-Rate, Decoder-Output-Rate, gewählter Modus und beobachtetes Ergebnis. Werden sie zu „Wideband“ verdichtet, kann ein standardkonformer Narrowband-Pfad als gelieferte Produkteigenschaft erscheinen.

Der Payload-Typ wählt ein Format, keinen Modus

audio/EVRCWB, EVRCWB0 und EVRCWB1 stehen für Interleaved/Bundled, Header-Free und Compact Bundled. Die Payload-Zuordnung sagt dem Empfänger, wie Bytes und Frames zu interpretieren sind.

Sie sagt nicht, ob der Encoder in Modus 0, 4 oder 7 arbeitet. Die Modi 4 und 7 sind mit EVRC-B interoperabel. Ein EVRC-WB-Offer sollte zusätzlich EVRC-B anbieten, damit ein Legacy-Answerer darauf zurückfallen kann.

Codec-Familie, Paketformat, Encoder-Modus und akustische Rate bilden daher keine einzige Eigenschaft. Eine korrekte Negotiation ist die Voraussetzung für Interpretation, nicht der Abschlussbeleg für die Ausführung.

Empfangspräferenz ist keine Fernsteuerung

Mit mode-set-recv nennt ein EVRC-WB-Empfänger die bevorzugte Menge entfernter Encoder-Modi. Mit recvmode nennt ein EVRC-B-Empfänger einen bevorzugten Modus. Beide Parameter sind receive-only.

Der entfernte Sender darf die Präferenz ignorieren. Der Empfänger soll weiter korrekt decodieren. RFC 5188 zeigt sogar einen Answerer, der Modus 4 sendet, obwohl der Offerer Modus 0 empfangen wollte.

Der Receipt muss deshalb Wunsch, Senderentscheidung, gemeldeten Zustand und tatsächlich ausgeführten Frame trennen. Ein vorhandenes Preference-Feld ist kein Enforcement-Nachweis; seine Nichtbefolgung ist nicht automatisch ein Protokollfehler.

Richtung verhindert herrenlose Claims

mode-set-recv und recvmode gehören zur Empfangsrichtung, sendmode zur Senderichtung. In einem sendonly Stream ist eine Empfangspräferenz nutzlos; in einem recvonly Stream ist eine Sendemodus-Meldung nutzlos.

Gateways, die alle Parameter symmetrisch kopieren, erzeugen vollständige Zeichenketten ohne zuständigen Akteur. Zu jedem Wert gehören Endpoint, Richtung, Payload-Bindung und Offer/Answer-Version.

Unbekannte Offer-Parameter müssen ignoriert und aus dem Answer weggelassen werden. Ein Echo würde Verständnis vortäuschen. Das Weglassen schützt die semantische Grenze.

Medien können die Meldung überholen

sendmode meldet den aktuellen Encoder-Modus. RFC 5188 warnt jedoch, dass RTP-Medien lange vor dem ersten oder aktualisierten SDP mit sendmode eintreffen können.

Wechselt der Encoder bei T1, treffen Pakete bei T2 und SDP bei T3 ein, ist die letzte bekannte Control-Aussage zwischen T1 und T3 veraltet. Nach T3 datiert die Meldung frühere Pakete nicht rückwirkend.

Eine belastbare Rekonstruktion verbindet Offer/Answer-Version, Encoder-Umschaltung, RTP sequence und timestamp, Versand, Empfang und Decoder-Ingestion. Späte Signalisierung ist nicht automatisch Fehlkodierung; endgültige Übereinstimmung löscht die Zwischenzeit aber nicht.

Legacy-Abwesenheit bleibt mehrdeutig

RFC 5188 ergänzt recvmode und sendmode für EVRC-B aus RFC 4788. Alte Implementierungen senden die Attribute nicht und ignorieren sie beim Empfang. Genau so bleibt Interoperabilität erhalten.

Abwesenheit kann Legacy, optionale Auslassung, Normalisierung oder unvollständige Erfassung bedeuten. Sie darf nicht automatisch in Modus 0, Ablehnung oder Non-Compliance übersetzt werden.

Version und Capability müssen erhalten bleiben. Erst dann kann ein fehlendes Feld als erwartete Kompatibilität, Datenverlust oder unbekannter Zustand klassifiziert werden.

EVRCWB1 verlangt eine harte Session-Grenze

EVRCWB1 muss über die ganze Session dieselbe feste Rate und denselben Modus verwenden. Ein Wechsel unter derselben Identität unterscheidet sich von erlaubten Übergängen anderer Formate.

Eine spätere gültige SDP reicht nicht. Nachzuweisen sind Ende der alten Bindung, Beginn einer neuen Session oder Payload-Bindung und die Zugehörigkeit jedes Pakets. Die feste Regel stärkt den Identitätsbeleg; sie macht die Empfangspräferenz nicht zum Ausführungsbeleg.

Der erforderliche Evidence Record

Er beginnt mit unveränderlicher Session- und Change-ID, Rollen, Richtungen, Offer/Answer-Versionen, Payloads, Subtyp, Clock und rohen rtpmap-, fmtp-, ptime- und maxptime-Zeilen.

Danach folgen Präferenz und Eigentümer, Sender-Policy, jedes sendmode samt Empfangszeit, Encoder-Transition sowie sequence, timestamp, Ankunft und beobachteter Modus relevanter Frames. Legacy-Capability, Unknown-Parameter-Verhalten und EVRCWB1-Invariante gehören dazu.

Decoder-Akzeptanz, Ausgabe und Anwendungsergebnis schließen die Kette. Decodierbarkeit beweist keine bevorzugte Betriebsart; eine Betriebsart beweist keine akustische Qualität.

Führungsentscheidung

Berichte müssen benennen, welche Realität sie messen. Transportzeit ist nicht Aufnahmebandbreite, Negotiation ist nicht Encoder-Ausführung und Präferenz ist nicht Kontrolle.

Wer diese Grenzen im Datenmodell erhält, kann Flexibilität zulassen und trotzdem Verantwortung zuordnen. Wer alles als „Wideband negotiated“ speichert, behält ein Label und verliert den Vorgang.

Quellen

  1. RFC 5188 HTML
  2. RFC 5188 Text
  3. RFC-5188-Information
  4. Datatracker RFC 5188
  5. RFC-5188-Historie
  6. RFC-5188-Referenzen
  7. RFC-5188-Errata
  8. RFC 4788
  9. RFC-4788-Information
  10. RFC 3558
  11. RFC-3558-Information
  12. RFC 3264 Offer/Answer
  13. RFC-3264-Information
  14. RFC 4566 SDP
  15. RFC 3550 RTP
  16. IANA audio/EVRCWB
  17. IANA RTP Parameters
  18. Heng Lu — Realitätsebenen
  19. Heng Lu — minimale Anfangsspezifikation
  20. Heng Lu — laufender Code zuerst