Zusammenfassung

  • RFC 3952 übertrug keinen iLBC-Frame-Zähler; der Empfänger teilte die RTP-Nutzlastlänge je nach SDP-Modus durch 38 oder 50 Oktette.
  • Ein 2026 gemeldetes und weiterhin als Reported geführtes Erratum schlägt 38/50 statt 32/50 vor; damit werden Paketform, Aushandlung, Schutz und Wiedergabe als getrennte Nachweise sichtbar.

Die Zahl wurde berechnet, nicht übertragen

Ein 20-ms-Frame umfasste 38 Oktette, ein 30-ms-Frame 50. RFC 3952 ließ mehrere Frames unmittelbar aufeinander folgen. Wer den Modus kannte, konnte aus der Gesamtlänge die Anzahl gewinnen.

76 Oktette ergaben unter Modus 20 zwei Frames, 100 unter Modus 30 ebenfalls zwei. Die Nutzlast trug den Dividenden; die Sitzung lieferte den Divisor. Eine Aufzeichnung, die RTP vollständig, aber SDP nicht bewahrte, konnte daher bytegenau und semantisch unvollständig sein.

Die Regeln schützten die Rechnung: Ein Frame durfte nicht auf zwei Pakete verteilt werden, beide Modi durften nicht in derselben Nutzlast stehen, und die Aggregation sollte den MTU-Rahmen respektieren. Wenige Frames bedeuteten weniger Paketierungsverzögerung und mehr Headerkosten; viele Frames bedeuteten das Gegenteil und bündelten mehr Sprachverlust in einem Datagramm.

Die Sitzung bestimmte die Einheit

SDP bezeichnete das Format als iLBC/8000; a=fmtp führte den mode. Ohne Angabe galt 30 ms. Für bidirektionale Sitzungen musste das Ergebnis auf beiden Seiten gleich sein.

Angebot und Antwort durften unterschiedliche Wünsche nennen. Gemeinsam galt der bandbreitenärmere Modus. 50 Oktette je 30 ms verbrauchen pro Zeit weniger als 38 je 20 ms; deshalb lösen beide gemischten Beispiele in RFC 3952 zu mode 30 auf.

RFC 2327 definierte SDP, RFC 3264 das Offer/Answer-Modell und RFC 3550 Reihenfolge und Zeit in RTP. Eine erfolgreiche Aushandlung bewies nicht, dass jedes Medienpaket folgte; ein korrekter RTP-Zeitstempel nannte keine iLBC-Framegröße.

Ausgerechnet in der Division stand 32

Die Abschnitte 2 und 3.1 nennen 38 Oktette für 20 ms. Das passt auch zur Codec-Beschreibung in RFC 3951. Abschnitt 3.2 druckt beim Verfahren zur Frame-Zählung dagegen 32/50.

Auf der Errata-Seite schlägt ID 8866 seit dem 3. April 2026 38/50 vor. Der Status lautet Reported, nicht Verified. Die interne Evidenz für 38 ist stark; der Prozessstatus darf trotzdem nicht vorweggenommen werden.

Die Quellen belegen keinen bestimmten Ausfall, Angriff oder Herstellerfehler. Sie belegen eine Dokumentationskante: Wer das Gesamtwerk liest, sieht 38 mehrfach; wer nur einen Satz extrahiert, kann 32 übernehmen. Das Netzwerkpaket bleibt gleich, aber das Wissen des Parsers kann falsch sein.

Teilbarkeit war nur die erste Prüfung

114 Oktette lassen sich unter mode 20 restlos in drei Einheiten teilen. Das ist ein Framing-Nachweis. Es sagt nichts über gültige Codec-Bits, Absenderidentität, SRTP-Prüfung, Jitterpuffer, Decodererfolg oder hörbare Ausgabe.

RFC 3711 behandelt SRTP gesondert. Authentisierte Bytes können mit veraltetem Modus unbrauchbar sein; teilbare Klartextbytes authentisieren niemanden. Ein Rest weist auf Modusdrift, falschen Payload Type, Beschädigung oder lückenhafte Erfassung hin, bestimmt aber die Ursache nicht.

Der RFC-Editor-Eintrag nennt Dezember 2004 und den Status Experimental. Die bleibende Lehre lautet: Wenn ein Format redundante Metadaten entfernt, wandert deren Autorität in ein anderes System. Wird dieses System nicht mitarchiviert, wird Effizienz später zu Beweisverlust.

Quellen