Zusammenfassung

  • RFC 3555 ordnete Taktrate und Kanalzahl dem SDP-Attribut rtpmap zu, weil sie gemeinsam mit dem Kodierungsnamen die sitzungslokale Bedeutung einer RTP-Payload-Nummer herstellen.
  • Eine korrekte Taktangabe belegt weder den Takt beobachteter Pakete noch die Fähigkeit eines Endpunkts, die Kombination zu dekodieren oder nutzbare Medien auszugeben.

Die Zeichenfolge audio/L16; rate=48000; channels=2; ptime=5; emphasis=50-15 enthält mehrere Arten von Aussagen. RFC 3555 behandelte sie nicht als unteilbares Etikett. Beim Übergang in SDP wurde audio zum Mediennamen der m=-Zeile. L16, 48000 und zwei Kanäle wurden zu a=rtpmap:97 L16/48000/2. Der formatspezifische Wert emphasis kam in a=fmtp:97; die empfohlene Paketzeit in a=ptime:5.

Die Zahl 48000 beschreibt in diesem Vertrag den RTP-Zeitstempeltakt. Sie ist nicht automatisch eine Aussage über die Abtastrate einer gespeicherten Datei, die Hardware eines Abspielgeräts oder die Qualität des Ergebnisses. Der Platz im Protokoll begrenzt ihre Bedeutung.

Eine lokale Nummer erhält einen überprüfbaren Kontext

Die 97 im Beispiel ist dynamisch. Erst rtpmap bindet sie in dieser Sitzung an L16, Takt und Kanäle. Eine andere Sitzung darf 97 anders belegen oder L16 unter einer anderen Nummer führen. Wer nur RTP-Pakete archiviert und die Sitzungsbeschreibung verliert, kann aus der Nummer allein den Codec nicht zuverlässig rekonstruieren.

Umgekehrt beweist die Sitzungsbeschreibung keinen Datenstrom. Sie kann syntaktisch korrekt sein, obwohl der Sender andere Zeitstempelschritte verwendet, ein Endpunkt den Codec nicht besitzt oder die Parameterkombination ablehnt. Registrierung, Ankündigung, Annahme, Paket und Dekodierung sind getrennte Belege.

RFC 8866 hält diese Trennung in der heutigen SDP-Spezifikation fest. rtpmap ordnet einer Payload-Nummer Kodierungsname, Taktrate und Kodierungsparameter zu. fmtp transportiert formatspezifische Parameter zu einem Medienwerkzeug, ohne dass SDP selbst deren Inhalt verstehen muss.

Das Register durfte das Drahtformat nicht erweitern

RFC 3555 gab der Registrierung eine enge Rolle. Sie konnte erklären, wie Parameter aus der Medientyp-Zeichenfolge in fmtp überführt werden. Sie durfte aber die erlaubte Menge nicht ohne entsprechende Revision der Payload-Format-Spezifikation erweitern.

Damit blieb die Autorität dort, wo auch die Bits beschrieben waren. Ein privat eingeführter Schlüssel kann in zwei abgestimmten Produkten funktionieren. Er wird dadurch weder Teil des registrierten Formats noch für einen dritten Implementierer eindeutig. Selbst ein Parser, der den Schlüssel akzeptiert, hat dessen Semantik nicht bewiesen.

Auch die Groß- und Kleinschreibung wurde begrenzt behandelt. Kodierungsnamen und Parameternamen sind in den genannten Positionen nicht case-sensitiv, weil RTP-Profile häufig Großbuchstaben und Medientypen häufig Kleinbuchstaben zeigen. Daraus folgt nicht, dass beliebige Parameterwerte gefaltet werden dürfen.

Die Ablösung bewahrte den Kern und teilte die Pflege

RFC 4855 und RFC 4856 erklärten RFC 3555 im Jahr 2007 für obsolet. RFC 4855 übernahm Verfahren und Abbildung, passte sie an geänderte Medientyp-Regeln an und beschrieb Bedingungen für neue optionale Parameter. Bestehende Funktion durfte sich nicht ändern, und alte Implementierungen mussten den Zusatz ohne Störung ignorieren können.

RFC 4856 nahm die konkreten Registrierungen des Audio/Video-Profils auf und bezeichnete diese Neuordnung als technisch unverändert. Die Trennung erlaubte es, Registrierungsverfahren und Katalog in unterschiedlichen Zyklen zu pflegen, ohne das Payload-Format stillschweigend neu zu definieren.

Die eingefrorene IANA-Datei vom 6. Oktober 2026 enthält 165 Audio- und 97 Video-Einträge. Zwanzig verweisen direkt auf RFC 4856, darunter audio/L16, audio/PCMA und audio/PCMU. Das ist ein Nachweis über Registerzustand und Referenzkette. Es ist keine Inventur installierter Decoder.

RFC 3555 zeigt damit eine nüchterne Form von Portabilität. Ein Name kann in mehreren Beschreibungswelten bestehen, wenn Taktrate, Kanäle, Paketzeit und Formatspezifika jeweils sichtbar abgebildet werden. Wo Beobachtung beginnt, endet die Beweiskraft des Namens.

Quellen